Forms Development Environment, Setup, and Architecture
What to know
AEM Forms runs in two broad topologies: JEE (Foundation) and OSGi (Adaptive Forms on AEM). Know which capabilities belong to which. Document Services (Output, Forms, Assembler, PDF Generator, Reader Extensions) traditionally live on JEE but are also exposed as OSGi bundles/services; Adaptive Forms, form data models, and rules are OSGi-centric. Understand the repository layering: /content (authored assets), /conf (configuration and cloud configs, per-tenant), /etc (legacy clientlibs/designs), /apps (code and components), /libs (product code, never edit directly), and /var (runtime data).
Architecture concepts
Know the role of the Dispatcher (caching, security filter), Granite and Sling (resource resolution, servlets, OSGi), and the JCR (nodes, properties, nt:file for binaries). Understand the Forms portal, submission services, and the difference between publish and author tiers for form rendering. Know how watch folders and Output service are configured, and where PDF Generator fits (native vs PDFBox conversion).
Traps
Questions often confuse configuration location: cloud configurations go under /conf, not /etc. Another trap is assuming /libs can be modified - always overlay into /apps. Candidates also mix up which services need JEE versus OSGi. Finally, watch for the difference between a Forms Experience deployment and a standalone Adaptive Forms authoring instance.
Rule of thumb
If a setting is tenant-specific and reusable across sites, it belongs under /conf as a cloud configuration; if it is global runtime behavior, it belongs in OSGi config (configMgr).
Worked example
A team needs a shared Form Data Model across two sites. Correct approach: create the FDM under /conf/<tenant>/settings/cloudconfigs/... and reference it from both forms, rather than duplicating under each site's /content tree.