ArcGIS Enterprise Admin (EAEP) common mistakes
ArcGIS Enterprise Admin (EAEP) · Understand the traps and how to avoid them.
Treating ArcGIS Enterprise as a single product and describing the portal as if it were the whole system, so answers miss the base deployment components (portal, hosting server, ArcGIS Server, Data Store, web adaptors) and their distinct roles.
Many candidates come from ArcGIS Online or single-server ArcGIS Server backgrounds where one URL appears to do everything, so they collapse the multi-tier architecture into one box and lose track of which component owns which capability.
What to do instead
Draw the reference architecture from memory until it is automatic: portal for identity and content, hosting server for hosted layers, ArcGIS Server for services, relational and tile cache data stores for managed data, web adaptors for routing and TLS termination. For each practice question, name the component that performs the action before choosing an answer.
Confusing the roles of the portal's identity store with enterprise identity provider configuration, answering that adding users to an enterprise group in the portal is what grants access, or assuming portal administrators automatically gain ArcGIS Server administrative rights.
Portal accounts, enterprise identity provider accounts, and ArcGIS Server tokens are three separate authentication surfaces that interlock through the portal's security configuration; candidates memorize the UI labels without mapping which layer enforces each decision.
What to do instead
Build a one-page matrix of identity sources (built-in portal accounts, enterprise identity provider via SAML or OIDC, integrated Windows authentication) against what each can authenticate, and separately map authorization: portal roles, groups, sharing levels, and the separate privilege model for ArcGIS Server and the data store. Practice tracing a request from sign-in to service access step by step.
Assuming that publishing a feature layer always stores data in the registered enterprise geodatabase, and failing to distinguish hosted feature layers (data copied into the relational ArcGIS Data Store) from referenced, registered data.
The publishing workflow looks identical in the UI for both cases, and the choice of whether a data store item is registered determines where the data actually lives, who can edit it, and whether the data store is even required.
What to do instead
Before answering any publishing question, classify the layer as hosted or referenced and identify the backing store. Memorize that hosted feature layers require a relational data store and that registering a database or folder changes a layer from copied to referenced. Practice predicting the storage location from the publish options alone.
Mixing up the data store types and their failure behavior, for example expecting the spatiotemporal big data store to serve as the primary store for hosted feature layers, or assuming the tile cache data store is optional when the deployment uses the default scene and tile services.
The data store types are configured in one wizard and appear as similar entries, so candidates learn the names without learning which portal capabilities break when each type is missing or unhealthy.
What to do instead
Associate each store type with the capability it enables: relational for hosted feature layers and portal content, tile cache for cached map and scene services, spatiotemporal big data store for large-volume observational and tracking data, graph store for knowledge graph. Then practice the symptom-to-cause direction: which feature stops working when each store is down.
Answering licensing questions by counting named users only, ignoring the ArcGIS Server licensing roles and extension licenses that gate specific capabilities such as image services, network analysis, or geostatistical analysis.
Portal user types and ArcGIS Server licenses are separate entitlements, and the exam tests whether the candidate knows that a capability can be blocked by a missing server role or extension even when every user is correctly licensed.
What to do instead
Maintain a checklist mapping capabilities to the entitlement that enables them: user type and add-on apps for portal access, ArcGIS Server licensing role for the server tier, and named extensions for specific service types. When a scenario says a capability is unavailable, check the server license and extensions before checking user types.
Skipping the pre-installation and post-installation configuration steps in scenarios, such as ignoring the requirement to configure the portal's initial administrator, web adaptor registration order, or the DNS and certificate prerequisites that must exist before federation.
Candidates study the installation wizard but not the ordering constraints around it, and the exam often presents a scenario where a step performed in the wrong order produces a specific, diagnosable failure.
What to do instead
Write the deployment sequence as an ordered list including prerequisites: DNS names, certificates, database creation and permissions, component installation, web adaptor configuration, portal creation, federation, and data store registration. For each step, note what breaks if it is done out of order, and rehearse the sequence until the ordering is automatic.
Treating backup and restore as a single operation, so answers assume that backing up the portal also captures the hosting server and data store, or that restoring the portal alone returns hosted feature layers to service.
The backup tools are separate per component and the restore order matters; candidates who have only seen the portal backup utility assume it is comprehensive.
What to do instead
Learn the backup scope of each component: portal content and configuration, ArcGIS Server site configuration and services, and the separate data store backup utilities for each store type. Memorize that a full recovery requires all components restored to a consistent point, and practice describing the restore order and the validation checks after restore.
Diagnosing performance problems by recommending more hardware first, instead of checking the identifiable bottlenecks such as unindexed or versioned enterprise geodatabase data, unoptimized service configurations, missing tile caches, or log evidence of slow queries.
Hardware scaling is the intuitive answer and feels safe, while the exam expects the candidate to read logs, identify the slow layer, and choose a targeted remedy.
What to do instead
Adopt a fixed triage order for performance scenarios: identify the affected service, check logs for the slow operation, inspect the data source for indexing and versioning issues, review service instance and caching settings, and only then consider capacity. Practice matching each log symptom to a specific configuration change.
Confusing the web adaptor's responsibilities with those of the portal or server, for example expecting the web adaptor to authenticate users or to provide load balancing across multiple portal machines without an external load balancer.
The web adaptor sits at the front of the request path and is easy to describe as doing everything, but it forwards requests and handles URL rewriting and TLS termination, not identity decisions or high availability.
What to do instead
State the web adaptor's job in one sentence: accept client requests on a well-known URL and forward them to the configured portal or server. Then separately describe what provides high availability (multiple machines behind a load balancer) and what authenticates users (the portal's identity configuration). Test each scenario against that split.
Answering security scenarios by granting broad privileges or disabling security controls to resolve an access problem, rather than identifying the specific sharing, group membership, or role change that grants the minimum necessary access.
Under time pressure the shortest path to making an error message disappear is to elevate privileges, and candidates who have not internalized the least-privilege model choose the answer that removes the symptom rather than the cause.
What to do instead
For every access-control scenario, name the exact resource, the exact principal, and the minimum privilege that satisfies the requirement, then verify no broader grant is implied. Practice rejecting answers that expand access beyond the stated need, and rehearse the group and role model until the least-privilege option is the obvious one.