EGMP2201 Practice Questions

A database view is a stored SQL query that functions as a virtual table. A data administrator can create a view that selects only a specific subset of fields (columns) from the source feature class's business table. By granting user permissions on this view while revoking or denying permissions on the underlying base table, access to the sensitive fields is effectively restricted at the database level. This is a standard, robust security practice for implementing column-level security in an enterprise geodatabase, ensuring unauthorized users cannot access the restricted data regardless of the client application used.

A. Layer file: A layer file (.lyrx) only controls the display properties and field visibility within a specific ArcGIS Pro map or project; it does not enforce security at the data source.

B. Query layer: A query layer is an ArcGIS mechanism for displaying data from a SQL query, but it is not the fundamental database security object. The underlying security is managed by database permissions on views or tables.

1. Esri ArcGIS Pro Documentation, "Views in a geodatabase": "You can use views to control access to data by granting privileges on the view to specific users. This allows you to limit the columns (fields) or rows (features or records) the users can see." This document explicitly states that views are a primary method for restricting access to specific columns.

2. Esri ArcGIS Pro Documentation, "Data access and security": "To restrict access to certain columns in a table, you can create a view on the table that includes only the non-sensitive columns. Then grant privileges on the view to users and revoke privileges from the base table." This section provides a step-by-step conceptual model for the exact scenario in the question.

3. Pennsylvania State University, GEOG 485: GIS Database Development and Administration, Lesson 6: Multiuser Geodatabase Administration: The courseware explains security models, stating, "A common strategy for restricting access to certain rows or columns in a table is to create a database view...You can then grant privileges on the view to a role, and add users to that role." This confirms the use of views as a standard academic and professional practice for field-level security.

The question's premise is technically inaccurate, as editors in child versions must reconcile to see changes from the default version, regardless of the versioning type. However, interpreting the question's likely intent—to allow other applications or non-versioned users to see changes made to the default version—the correct answer is A. Registering a dataset as traditional versioned with the "move edits to base" option ensures that once edits are posted to the default version, they are written directly to the base business tables. This makes the changes immediately visible to any client or application reading the non-versioned state of the data, without requiring them to access a specific version.

B. Branch versioning is designed for feature service editing workflows and, like traditional versioning, requires a reconcile operation to update a child version with changes from default.

C. Enabling archiving creates a historical log of transactions for auditing or temporal analysis but does not alter the core versioning behavior of isolating edits until reconciliation.

---

1. Esri ArcGIS Pro Documentation, "Versioning options in ArcGIS Pro": This document explicitly states for the "Register as versioned with the option to move edits to base" setting: "When edits are saved, they are moved from the delta tables to the base tables... Because the edits are in the base tables, the data is accessible to other applications that may not be able to read the delta tables in a geodatabase." (Found under Manage Data > Geodatabases > Traditional versioning > Register data as versioned).

2. Esri ArcGIS Pro Documentation, "A tour of traditional versioning": This guide clarifies the standard workflow: "To merge the changes, you reconcile your version with the default version. This process applies the edits made in the default version to your version." This confirms that reconciliation is the required step for a child version to see parent changes. (Found under Manage Data > Geodatabases > Traditional versioning).

3. Esri ArcGIS Pro Documentation, "Overview of branch versioning": This document describes the branch versioning model, which is based on a service-oriented architecture. The workflow still involves discrete versions that must be reconciled to incorporate changes from other versions, such as default. (Found under Manage Data > Geodatabases > Branch versioning).

Scenario Overview:

The GIS data administrator needs to prepare data for offline workflows.

Offline workflows allow users to take data offline for use in disconnected environments, typically for

field operations.

Why Enable Sync?

Sync must be enabled on the feature service to allow offline workflows. This capability ensures that

edits made offline can later be synchronized with the enterprise geodatabase.

When sync is enabled, data can be downloaded for offline use in supported applications like ArcGIS

Field Maps, and changes can be synchronized back to the geodatabase.

(ArcGIS Documentation: Sync)

Alternative Options:

Option A: Enable Archiving

Archiving tracks historical edits but is not required for offline workflows.

Option B: Add Global IDs

While Global IDs are required for enabling sync, adding them alone does not fully configure the

dataset for offline workflows.

Thus, to prepare data for offline workflows, the administrator must enable sync on the dataset.

The most significant performance bottleneck when appending a large volume of spatial data (20 million rows) is the continuous, row-by-row maintenance of the spatial index. Each inserted feature requires a computationally expensive update to the complex grid structure of the spatial index. The established best practice for bulk data loading is to drop the spatial index before the operation, append the data to the table, and then rebuild the index once. This single, holistic index creation process is vastly more efficient than millions of individual index updates. The scenario already correctly follows this practice for the attribute index, making the spatial index the remaining and most impactful element to address.

A. The ObjectID is the primary key, and its index is highly optimized and generally cannot or should not be dropped. The performance overhead is minimal compared to a spatial index.

C. Adding a unique key index before a bulk append is counter-productive. It would force the database to validate and update the index for each row, severely degrading performance.

1. Esri ArcGIS Pro Documentation: In the section on data loading strategies, Esri explicitly recommends this approach. "For very large loads, you can improve performance by dropping indexes, loading data, and re-creating the indexes. This applies to both attribute and spatial indexes."

Source: Esri ArcGIS Pro Documentation, "Strategies for data loading," section "Load data into an existing feature class or table."

2. Esri ArcGIS Enterprise Documentation: The documentation on geodatabase administration reinforces this principle for managing large datasets. "When loading large amounts of data... it is almost always faster to drop the indexes, load the data, and rebuild the indexes."

Source: Esri ArcGIS Enterprise Documentation, "Geodatabase management in SQL Server," section "Create spatial and attribute indexes."

3. Pennsylvania State University, GEOG 868: Course materials for Geodatabase Development and Management outline best practices. "A common strategy for loading large datasets is to first drop any indexes on the table (except the ObjectID index), load the data, then rebuild the indexes. This is especially true of spatial indexes, which can be time-consuming to maintain on a row-by-row basis."

Source: Penn State University, John A. Dutton e-Education Institute, GEOG 868: Geodatabase Development and Management, Lesson 5: "Loading and Maintaining Data."

A mosaic dataset is the optimal storage mechanism for this scenario. It is a data model within an enterprise geodatabase specifically designed to manage, view, and query large collections of raster and image data. It stores metadata and references to the source imagery (which can remain in a centralized folder) rather than the pixels themselves. This allows for dynamic mosaicking, on-the-fly processing, and efficient serving of imagery as a single layer across an organization, which directly meets the administrator's requirements for enterprise-wide access.

A. Raster dataset: A raster dataset typically represents a single raster image. It is not designed to manage or visualize a collection of multiple images as a single, cohesive layer.

B. Raster catalog: A raster catalog is a legacy data model for managing collections of rasters. While functional, it has been largely superseded by the mosaic dataset, which offers superior performance and more advanced capabilities.

1. Esri ArcGIS Pro Documentation, "What is a mosaic dataset?": "A mosaic dataset is a data model in the geodatabase that is used to manage a collection of raster datasets (images) stored as a catalog and viewed as a single mosaicked image." This source confirms its purpose for managing collections.

2. Esri ArcGIS Pro Documentation, "Fundamentals of raster storage": In the section comparing storage options, it states, "Mosaic datasets are ideal for managing and visualizing large collections of imagery... They are also the best way to serve imagery." This highlights its suitability for enterprise access.

3. Esri ArcGIS Pro Documentation, "Raster catalog properties": "Raster catalogs are useful for displaying adjacent, non-overlapping raster datasets... If you have overlapping raster datasets, it is recommended that you use a mosaic dataset." This indicates the mosaic dataset is the more modern and recommended approach.

The post operation fails because the target version, Default, is set to protected. A protected version can only be modified by its owner or a geodatabase administrator. Posting edits from a child version is considered a modification of the parent version. Since the editor is not the owner of the Default version, they lack the necessary permissions to complete the post. The standard workflow in this scenario is for the editor to perform the reconcile to check for conflicts, and then have a user with the appropriate permissions—the owner of Default or a geodatabase administrator—perform the post.

A. Changing the child version's access level does not grant the editor permission to modify the protected parent (Default) version.

C. Replication is a data distribution and synchronization mechanism, not the standard procedure for merging edits into a protected parent version within the same geodatabase.

1. Esri ArcGIS Pro Documentation. (n.d.). Reconcile and post edits. In ArcGIS Pro 3.2 Help. Retrieved from https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/overview/reconcile-and-post-edits-to-a-version.htm

Reference Specifics: Under the section "Post edits," the documentation states: "If the target version's access is set to protected, you must be the owner of the target version or the geodatabase administrator to be able to post your edits." This directly explains why the editor's post operation fails and supports the solution in option B.

2. Esri ArcGIS Pro Documentation. (n.d.). Version access permissions. In ArcGIS Pro 3.2 Help. Retrieved from https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/overview/version-access-permissions.htm

Reference Specifics: The definition for "Protected" access states that only the owner or geodatabase administrator can edit the version. This establishes the permission restriction that is the root cause of the problem described in the question.

3. Pennsylvania State University. (2024). Multiuser Geodatabase Editing. In GEOG 485: GIS Database Development. Penn State College of Earth and Mineral Sciences. Retrieved from https://www.e-education.psu.edu/geog485/node/55

Reference Specifics: In the "Versioning Workflows" section, the courseware describes a common quality assurance workflow where editors work in child versions and a QA/QC manager, who has higher privileges, is responsible for reconciling and posting the edits to the protected Default version. This aligns with the solution presented in option B.

The steady performance degradation is caused by the unreconciled read-only versions. In a versioned geodatabase, each version maintains a lineage of database states back to its creation. The nightly COMPRESS operation can only remove states and associated delta table records that are no longer referenced by any version's lineage. Because the read-only versions are never reconciled, they hold references to very old database states. This prevents the COMPRESS operation from cleaning up the state tree and moving records from the delta (A and D) tables to the base tables. Over months, this leads to an increasingly large and complex state tree, which severely degrades query performance for all users. Reconciling these versions updates their lineage to a more current state, allowing COMPRESS to be effective.

B. Create a database view: This is a data access method and does not resolve the underlying geodatabase maintenance issue. A view on the versioned data would still suffer from the poor performance.

C. Disable editor tracking: Editor tracking adds minimal overhead to edit operations. It is not the cause of the systemic, long-term performance degradation described, which is characteristic of versioning maintenance issues.

1. Esri ArcGIS Pro Documentation, "The geodatabase compress operation": "The compress operation removes unreferenced states and their associated delta table rows... A state is part of a version's lineage if it is the state the version was created in, the state the version is currently pointing to, or any state in between." This confirms that unreconciled versions prevent states from being removed.

2. Esri ArcGIS Pro Documentation, "Versioning scenarios": In the section on long-term projects, it is noted that "long-term versions can lead to a deep state tree, which can affect performance." The scenario describes long-lived, unreconciled versions which have the same effect.

3. Esri White Paper, "ArcGIS Versioning Best Practices" (July 2012), Page 6, "Compressing the Geodatabase": "It is important to understand that long-term versions can have an impact on the performance of the compress command... The compress command will not be able to compress any states in the direct lineage of the version." This directly links long-term (unreconciled) versions to compress ineffectiveness and performance issues.

The Protected access level is the correct and most secure setting for the default version in a production enterprise environment. This configuration allows all portal users to view the data, fulfilling its role as the published version. Critically, it restricts direct editing and the ability to post changes to only the version owner (typically a data administrator) and the geodatabase administrator. This prevents general editors from modifying the authoritative default version directly, thereby ensuring data integrity. It enforces a controlled workflow where edits from named versions are reviewed and then formally posted by an authorized user, which is a standard best practice.

A. Public: This setting would allow any user with editor permissions to modify the default version directly, bypassing controlled review workflows and risking the integrity of the published data.

C. Private: This setting would restrict viewing access to only the version owner and administrator, which contradicts the requirement that the version is visible to all portal users.

1. Esri ArcGIS Pro Documentation, "Version access" section in "Manage branch versions": This document defines the three access levels. For Protected, it states, "Any user can view the named version, but only the owner or the geodatabase administrator can edit the version and post changes to it." This confirms that Protected allows viewing while restricting edits to authorized roles, safeguarding the default version.

(Found under ArcGIS Pro > Help > Data > Geodatabases > Overview > Manage branch versions)

2. Esri ArcGIS Pro Documentation, "Reconcile and post edits to a branch version": This page clarifies the permissions needed for the post operation. It specifies, "To post, the portal account must also have access to edit the default version." This technical requirement supports the choice of Protected, as it centralizes the post operation with the owner/administrator who has edit rights, thus creating a controlled update process.

(Found under ArcGIS Pro > Help > Data > Geodatabases > Overview > Reconcile and post edits)

3. Esri ArcGIS Pro Documentation, "Share branch versioned data": This document outlines the standard workflow, describing the default version as the published representation of the data. It emphasizes that edits occur in named versions, which are then integrated back into default. A Protected default version is the mechanism that enforces this separation and control.

(Found under ArcGIS Pro > Help > Sharing > Overview > Share branch versioned data)

Geodatabase replication requires that the schema of the replicated datasets be identical across all replicas for data synchronization to succeed. In this scenario, a new field (legalarea) was added to the feature class in the parent geodatabase but not in the child. When the parent attempts to synchronize, it will try to send data edits related to this new field. The child geodatabase's feature class lacks the corresponding legalarea field to receive these edits. This schema mismatch prevents the synchronization process from applying the changes, resulting in a failure and an error message.

B. The synchronization adds the missing field: Data synchronization is designed to exchange row-level edits (inserts, updates, deletes), not to automatically propagate schema-level changes like adding fields. Schema modifications require a separate, explicit workflow.

C. The synchronization succeeds: The synchronization cannot succeed because there is a fundamental schema inconsistency. The process will fail when it attempts to populate a field in the child replica that does not exist.

1. Esri ArcGIS Pro Documentation, "Geodatabase replication and schema changes." This document states, "Before synchronizing data edits, you must apply any schema changes to both the parent and child replicas. If you synchronize data edits before applying schema changes to both replicas, the synchronization will fail." This directly supports the conclusion that a schema mismatch causes an error.

2. Esri ArcGIS Pro Documentation, "Replication and geodatabase compatibility." This resource establishes the foundational requirement: "For data to be replicated, the source and destination geodatabases must have the same schema. This includes the logical name of tables and fields, field types, and so on." The scenario violates this core principle.

3. Pennsylvania State University, GEOG 868: Geodatabase Administration. Course materials for advanced GIS often cover replication. Lesson 5, "The Multiuser Geodatabase," discusses the strict requirements for maintaining schema consistency in replicated environments, noting that unmanaged schema divergence is a common source of synchronization failure. This reinforces the principle that schema must be managed deliberately.

The required changes—a new geodatabase name and altering the repository owner from SDE to DBO—are fundamental configuration settings established during the geodatabase's initial creation. The only workflow that accommodates these specific changes is to create a new, empty enterprise geodatabase on the target server. During this process, the administrator can define the new name and use the "Enable Enterprise Geodatabase" tool to specify 'DBO' as the geodatabase administrator, which in turn creates the repository tables in the DBO schema. After the new geodatabase is correctly configured, data from the old geodatabase can be migrated into it using methods like XML workspace documents or copy/paste operations.

A. Restore a database backup: This method creates an exact replica of the source database, preserving the original geodatabase name and the 'SDE' schema owner. It does not allow for reconfiguration during the migration.

C. Migrate Storage geoprocessing tool: This tool is designed to change the underlying data storage format (e.g., from SDEBINARY to Geometry) for individual tables within an existing geodatabase, not to migrate the entire geodatabase or change its core properties.

---

1. Esri ArcGIS Pro Documentation, "Enable an enterprise geodatabase in SQL Server": This document outlines the process of creating a geodatabase. It explicitly states, "If the geodatabase administrator is the dbo user, the geodatabase system tables, views, functions, and stored procedures are created in the dbo schema." This confirms that specifying the owner is part of the creation/enablement process.

Source: Esri ArcGIS Pro 3.2 Documentation, "Data management" > "Geodatabases" > "Administer" > "Enable an enterprise geodatabase in SQL Server".

2. Esri ArcGIS Pro Documentation, "Geodatabase migration options": This page discusses different strategies for moving a geodatabase. It implicitly supports the "create new and load data" approach for scenarios where the target configuration (like schema or name) must be different from the source, as opposed to a simple backup/restore for identical moves.

Source: Esri ArcGIS Pro 3.2 Documentation, "Data management" > "Geodatabases" > "Administer" > "Geodatabase migration options".

3. Esri ArcGIS Pro Tool Reference, "Migrate Storage (Data Management)": The official tool documentation clearly defines its limited scope. The summary states: "Migrates the storage of a geodatabase table or feature class from one storage type to another." This confirms it is not a tool for migrating an entire geodatabase to a new server or changing its owner.

Source: Esri ArcGIS Pro 3.2 Documentation, "Tool Reference" > "Data Management toolbox" > "Geodatabase Administration toolset" > "Migrate Storage".