nerdexam
Adobe

AD0-E117 · Question #25

A customer has an international presence and a strong brand image. The customer considers the exceptional quality images used for both print and on the website to be essential for its business, The…

The correct answer is A. Train the design team to upload smaller assets and save the originals elsewhere D. Split AEM Assets and Sites in two different stacks and use Connected Assets. Uploading 500MB source images forces AEM's rendition workflows (ImageMagick/FFmpeg) to run on the same infrastructure serving authors and publishers, which explains the instability and slowness - A eliminates this at the source by keeping large originals outside AEM and…

Design and Architecture

Question

A customer has an international presence and a strong brand image. The customer considers the exceptional quality images used for both print and on the website to be essential for its business, The customer uses AEM 6.5 managed services with a configuration of 2 dispatchers, 2 publishers, and 1 author. The original images can weigh up to 500Mb with videos weighing even more. Renditions are generated after files are uploaded to AEM DAM by the Design team so the Authoring team can use them on the website. The teams report issues with platform stability and slowness. Visitors report that images look pixelated on some screens and pages are very slow to load. Which two actions should the Architect take to resolve these issues? (Choose two.)

Options

  • ATrain the design team to upload smaller assets and save the originals elsewhere
  • BAllocate more memory to ImageMagick and FFmpeg
  • COptimize renditions for the different viewports used by the visitors
  • DSplit AEM Assets and Sites in two different stacks and use Connected Assets
  • EAdd more dispatchers and publishers to the AEM configuration

How the community answered

(28 responses)
  • A
    64% (18)
  • B
    7% (2)
  • C
    18% (5)
  • E
    11% (3)

Explanation

Uploading 500MB source images forces AEM's rendition workflows (ImageMagick/FFmpeg) to run on the same infrastructure serving authors and publishers, which explains the instability and slowness - A eliminates this at the source by keeping large originals outside AEM and uploading only optimized versions. D is the correct architectural fix: AEM's Connected Assets feature lets you split the DAM (asset processing) into its own dedicated stack, so heavy rendition generation no longer competes with Sites authoring and publishing for resources.

B is wrong because throwing more memory at ImageMagick/FFmpeg is a band-aid - the real problem is that files this large should never enter AEM at all. C addresses the pixelation symptom but not the stability root cause, and rendition optimization is meaningless if the platform is too unstable to generate them reliably. E is wrong because adding dispatchers/publishers scales the delivery tier, but the bottleneck is upstream on the author/DAM processing side, not content serving.

Memory tip: Think "fix the intake, isolate the load." Bad input (giant files) → fix at the source (A). Asset processing vs. content delivery on one stack → separate them (D). Any answer that only adds hardware or tweaks settings without changing the architecture is a distractor.

Topics

#AEM DAM Performance#Connected Assets#Asset Renditions#Architecture Topology

Community Discussion

No community discussion yet for this question.

Full AD0-E117 Practice