ArcGIS Enterprise Admin (EAEP) study materials
ArcGIS Enterprise Admin (EAEP) study resources

ArcGIS Enterprise Admin (EAEP) study plan

ArcGIS Enterprise Admin (EAEP) · Give each week a clear focus.

8 weeks · About 7 hours per week

Week 1

ArcGIS Enterprise architecture and components

  • Diagram the full ArcGIS Enterprise base deployment from memory: portal, hosting server, federated servers, data store, and web adaptors, labeling which component terminates TLS and which holds the sharing model.

  • Distinguish the roles of the portal, the hosting server, and federated servers by writing one sentence per component describing what breaks elsewhere if it goes offline.

  • Explain the relationship between an ArcGIS Web Adaptor, the reverse proxy pattern, and the context URLs each component is configured with, and predict the failure mode when context URLs and web adaptor URLs disagree.

  • Compare single-machine base deployments with multi-machine and high-availability layouts, listing the minimum number of machines and the shared dependencies for each.

Your checkpoint

A one-page hand-drawn architecture diagram of a high-availability base deployment with every component, port, context URL, and federation trust direction annotated, plus a 300-word written explanation of failure propagation.

Week 2

ArcGIS Enterprise architecture and components & Installation, configuration, and licensing

  • Sequence the installation order for portal, server, web adaptors, and data store, and justify why that order matters for federation.

  • Identify the prerequisites that must be satisfied before running each installer, including operating system, .NET, browser, and account requirements.

  • Map each license file and authorization file to the component that consumes it, and describe how licensing behaves in a multi-machine deployment.

  • Draft the post-install configuration checklist: initial administrator account, security question recovery, and the first federation of a server to the portal.

Your checkpoint

A numbered installation runbook covering all components in order, with prerequisites, license file placement, and verification steps a second administrator could follow without asking questions.

Week 3

Installation, configuration, and licensing

  • Configure a portal's initial administrator, identity store choice, and content directory location, and record the exact settings that are painful to change later.

  • Explain how the portal's built-in identity store differs from enterprise identity stores and when each is appropriate.

  • Describe how to add a second machine to a portal or server site and what must be identical across machines.

  • Produce a licensing inventory that states what happens to the deployment when a license expires or an authorization file is not applied.

Your checkpoint

A configuration decision record listing at least eight portal and server settings chosen before go-live, each with the chosen value, the reason, and the cost of changing it after content exists.

Week 4

Security, authentication, and access control

  • Compare portal-tier authentication with web-tier authentication, and state which components must be configured for each and where the identity token originates.

  • Configure an enterprise identity store with at least one group, then map that group to a portal group and trace how membership flows through.

  • Assign custom roles and privilege sets, and explain how to verify that a low-privilege member cannot publish a restricted service.

  • Explain how to designate an initial administrator, how to recover from a lost administrator account, and why the built-in account should not be used for daily work.

Your checkpoint

A written access-control test plan with at least ten concrete test cases (actor, action, expected allow or deny, and which log records the outcome) covering anonymous, member, publisher, and administrator roles.

Week 5

Data stores, content management, and publishing

  • Differentiate the managed relational data store, the graph store, and the spatiotemporal big data store by which service types depend on each.

  • Describe how to register a database or file share with a federated server, and contrast registered data with data copied into the managed data store.

  • Walk through publishing a feature layer from a registered enterprise geodatabase, naming each step where credentials or connection properties are stored.

  • Explain how hosted feature layer ownership, item-level sharing, and group sharing interact when content is moved between owners.

Your checkpoint

A data store registration and publishing checklist that covers connection properties, credential storage, item ownership, and the verification query to run after publishing.

Week 6

Data stores, content management, and publishing & Maintenance, monitoring, and performance

  • Plan a backup strategy that covers the portal content directory, the server configuration store, the managed data stores, and the enterprise geodatabases, and state the restore order.

  • Identify which logs to consult for portal, server, data store, and web adaptor problems, and describe what each log reveals that the others do not.

  • Set up monitoring of service health and system resource usage, and define thresholds that would trigger an administrator to act.

  • Describe routine maintenance tasks with their recommended cadence: clearing caches, checking disk growth in the content directory and data stores, and reviewing logs.

Your checkpoint

A one-page backup-and-restore runbook listing every component to back up, the method, the frequency, the restore order, and a post-restore verification step for each.

Week 7

Maintenance, monitoring, and performance

  • Diagnose a slow service by separating portal, server, data store, and database causes and naming the evidence that points to each.

  • Explain how to tune the hosting server and managed data store for load, including instance limits, memory, and storage placement.

  • Interpret the relationship between service instance counts, machine resources, and the failure modes that appear when instances exceed capacity.

  • Describe how to scale out by adding machines to a site and what must be verified before directing traffic to the new machine.

Your checkpoint

A troubleshooting decision tree for 'the map is slow' with at least eight branches, each naming a diagnostic step and the log or metric that confirms or rules out that cause.

Week 8

ArcGIS Enterprise architecture and components & Installation, configuration, and licensing & Security, authentication, and access control & Data stores, content management, and publishing & Maintenance, monitoring, and performance

  • Re-derive the full architecture and installation sequence from memory and compare it against the week 1 and week 2 deliverables, correcting gaps.

  • Review every weak area identified in earlier weeks and rewrite the relevant checklist section with corrected detail.

  • Practice explaining, without notes, how authentication, federation, and data store registration depend on one another.

  • Take a timed practice assessment and categorize every missed item by domain to target final review.

Your checkpoint

A consolidated one-page quick-reference sheet covering architecture, licensing, authentication mode selection, data store types, and the top five maintenance tasks, plus a scored practice assessment with a per-domain error tally.

Milestones

Week 2: You can draw the high-availability base deployment from memory and recite the installation order with the reason for each step, without consulting notes.

Week 4: You can explain portal-tier versus web-tier authentication, name the component that issues the identity token in each, and pass at least eight of ten access-control test cases against a configured group and custom role.

Week 6: You can state the restore order for a full deployment and name the log or metric that would confirm each of the four most common failure categories.

Week 8: You score at least 80 percent on a timed practice assessment with no domain below 70 percent, and your quick-reference sheet covers all five domains without referring back to earlier deliverables.