NS0-077 NetApp StorageGRID Administrator Exam Questions and Answers

StorageGRID HA groups use an explicit interface priority order. The first interface in that order is the Primary interface and normally hosts all virtual IP addresses assigned to the HA group. If the Primary interface becomes unavailable, StorageGRID automatically moves the VIP addresses to the highest-priority backup interface that remains operational.

Importantly, this behavior includes automatic failback. NetApp states that when the failure is resolved and a higher-priority interface becomes available again, the VIP addresses are automatically moved to the highest-priority available interface. Therefore, once the original Primary interface is restored and considered healthy, StorageGRID automatically transfers the VIP back to it. No administrator intervention or Load Balancer service restart is required.

Options A and C are incorrect because restarting the Load Balancer service is not part of the standard HA failback workflow. Option B is also incorrect because StorageGRID does not permanently leave the VIP on a lower-priority backup interface after the preferred interface has recovered. The configured priority order continues to determine which interface should host the HA group's VIPs.

Reference topics: Grid Manager → High Availability Groups → Interface Priority → Primary/Backup Interfaces → VIP Failover and Automatic Failback

In StorageGRID, group policies are attached to a specific tenant group and define which S3 resources members of that group are permitted or denied access to. NetApp explicitly states that a group policy applies to only one group and can apply to multiple buckets. This makes B the correct answer.

Group policies are configured through Tenant Manager or the Tenant Management API and use AWS-compatible JSON policy syntax. A single group policy can therefore contain multiple Resource entries referencing different buckets and objects. In contrast, a bucket policy is attached to one specific bucket and can grant or deny access to multiple users or groups.

Options A and C are incorrect because StorageGRID does not assign precedence among group, bucket, and session policies. NetApp states that there is no difference in priority among these policy types. Authorization is determined by evaluating the applicable policy statements, with an explicit Deny overriding an Allow; it is not based on one policy class automatically taking precedence over another.

Option D reverses the relationship: it describes the scope of a bucket policy rather than a group policy.

Reference topics: Tenant Manager → S3 Access Management → Group Policies → Bucket Policies → Session Policies → AWS Policy Language

The correct combination is read-after-new-write consistency with Balanced ingest. The workload contains log objects that are written once and subsequently read, so read-after-new-write provides the required behavior: StorageGRID guarantees read-after-write consistency for new objects, while maintaining high availability. NetApp recommends this consistency setting for most workloads. Because these SIEM log objects are not expected to be updated after creation, the eventual-consistency behavior for updates is not material to this use case.

The ingest requirement is decisive. The EC7+5 placement spans three sites, but clients must remain able to ingest when one site is unavailable. With Strict ingest, StorageGRID must satisfy the ILM placement instructions synchronously before acknowledging the write. If the required EC placement cannot be created because a site is down, the request fails. In contrast, Balanced attempts the specified ILM placement immediately but, when an outage prevents that placement, StorageGRID falls back to dual-commit protection and acknowledges the object. ILM subsequently creates the required EC7+5 placement when resources become available again.

all is inappropriate because it requires every metadata node to receive metadata immediately, reducing availability during failures. Therefore, D satisfies both immediate visibility of newly written logs and continued ingest during a site outage.

Reference topics: S3 Bucket Consistency → Read-after-new-write → ILM Ingest Behavior → Balanced vs Strict → Erasure Coding → Multisite Availability

StorageGRID diagnostic information requested by NetApp Support can be collected through the Grid Manager log-collection interface . NetApp documents SUPPORT > Tools > Log collection as the standard StorageGRID mechanism for gathering logs, configuration data, system information, and other diagnostic content from selected grid nodes. The resulting .tar.gz archive can be downloaded or sent to NetApp Technical Support.

NetApp Active IQ OneCollect is also a NetApp diagnostic collection framework that supports StorageGRID environments and can collect consolidated support information for troubleshooting. NetApp documentation identifies OneCollect as a mechanism for gathering diagnostic data from supported NetApp systems, including StorageGRID, and making that information available for support analysis.

Lumberjack is a StorageGRID node-level troubleshooting utility and remains useful for specialized log collection, but for this question's wording—specifically generating and uploading support data through the NetApp support workflow—the intended choices are OneCollect and Grid Manager log collection .

StorageGRID requires an ADC service quorum at each site at all times. The ADC service maintains grid topology information and provides configuration services used throughout the grid. StorageGRID therefore prevents the decommissioning of a Storage Node if removing that node would violate the site's ADC quorum requirements.

StorageGRID 12.0 provides a supported Move ADC procedure specifically for situations where an administrator needs to decommission a Storage Node hosting ADC. The ADC service can be moved to another eligible Storage Node within the same site. The target must not already host ADC and must be either a combined Storage Node or metadata-only Storage Node. NetApp performs the operation through the Grid Management private API, using POST /private/move-adc/start; progress can be monitored with GET /private/move-adc. The dependent IDNT, ACCT, and RSM services move automatically with ADC.

Option B is invalid because ADC runs on eligible Storage Nodes, not Admin Nodes. Option C is incorrect because StorageGRID 12.0 documents the migration through the Grid Management API rather than a CLI relocation command. Option D is unsupported; administrators do not manually reinstall ADC.

Therefore, A is correct.

Reference topics: StorageGRID Maintenance → Move ADC → ADC Quorum → Storage Node Decommission → Grid Management API

When a physical or virtual host containing multiple StorageGRID nodes fails, NetApp defines a specific recovery-order requirement when one of those nodes is the primary Admin Node. StorageGRID 12.0 documentation states that if the failed server hosts the primary Admin Node, the primary Admin Node must be recovered first. This prevents subsequent node-recovery operations from stopping while attempting to communicate with services associated with the primary Admin Node.

Therefore, the administrator should deploy a replacement VM for the primary Admin Node and perform the documented primary Admin Node recovery. After the primary Admin Node is operational, recovery of the failed Gateway Node can proceed, restoring the intended client load-balancing path.

Option A is invalid because StorageGRID does not permit adding a primary Admin Node through an expansion; the primary Admin Node is established during initial installation and a failed one must be recovered. Options B and D incorrectly prioritize the Gateway Node while the failed host also contains the primary Admin Node. The StorageGRID 12.0 recovery guidance explicitly requires the primary Admin Node to be handled first in this situation.

Reference topics: Maintenance → Node Recovery → Primary Admin Node Recovery → Multiple Nodes on Failed Host → Gateway Node Recovery → Load Balancer Service

The ILM placement unachievable alert means that StorageGRID is unable to satisfy one or more placement instructions defined by an active ILM rule for certain objects. NetApp defines this alert as indicating that an ILM placement instruction cannot be achieved for certain objects, commonly because a required Storage Node or storage location is temporarily unavailable or because the ILM rule specifies a placement that the current topology cannot satisfy.

Therefore, D is the most accurate answer. The alert does not inherently mean that every S3 PUT operation failed. Whether a client PUT fails depends on the ILM rule's ingest behavior. With Strict ingest, StorageGRID must create all placements specified by the ILM rule immediately, so a placement failure can cause the client PUT to fail. With Balanced ingest, StorageGRID can temporarily use alternate protection and complete the required ILM placement later.

This distinction makes option C too absolute. Options A and B are unrelated to the meaning of the alert. NetApp also notes that ILM placement unachievable can occur while Storage Nodes are stopped during an upgrade and can persist for up to one day afterward, which is directly relevant to this post-update scenario.

Reference topics: Grid Manager → Alerts → ILM Placement Unachievable → ILM Placement Instructions → Balanced and Strict Ingest Behavior → Upgrade/Hotfix Monitoring

StorageGRID evaluates ILM rules sequentially from the top of the active policy. As soon as an object matches a rule, that rule's placement instructions are applied and the object is not evaluated against subsequent rules. Therefore, the rule containing the specific status=archive filter must appear before the catch-all rule.

In option A, objects tagged status=archive match Rule 1 and receive 4+2 erasure coding at the designated single-site storage pool. StorageGRID supports 4+2 erasure coding in a one-site storage pool provided that at least six data-capable Storage Nodes are available; seven are recommended.

Objects without the archive tag do not match Rule 1 and proceed to Rule 2. Rule 2 serves as the default rule, providing two replicated copies across the required sites. NetApp requires the default rule to be last and to have no filters, ensuring that it catches every object not matched earlier.

Option C is incorrect because its unrestricted first rule would match every object, preventing the archive-specific rule from ever being evaluated. B applies the protection methods to the wrong object classes, while D provides no rule for non-archive objects.

Reference topics: ILM Policies → Rule Evaluation Order → Advanced Filters/Object Tags → Default Rule → Replication → Single-Site Erasure Coding

The required consistency level is strong-global, specifically using the Quorum strong-global semantics available in StorageGRID 12.0. NetApp defines strong-global as guaranteeing read-after-write consistency for client requests across all sites. With Quorum semantics enabled, a grid containing three or more sites can tolerate a site failure while continuing client operations, provided the required metadata replica quorum remains available.

This directly matches the scenario. NetApp's multisite resiliency guidance states that, for a three-or-more-site deployment using Quorum strong-global, a single site plus a single node failure can occur without interruption to operations or metadata consistency, assuming sufficient object-data protection remains under the ILM configuration.

Option A, all, is unsuitable because every metadata node must acknowledge the update; if a node or site is unavailable, the request fails. Option C, strong-site, only guarantees immediate consistency within one site and does not provide the required global consistency. Option D provides read-after-write consistency for new objects but only eventual consistency for updates, so it does not satisfy the requirement that data remain consistently available for all read and write activity.

Reference topics: StorageGRID 12.0 → S3 Consistency → Strong-global → Quorum Semantics → Multisite Failure Tolerance → Metadata Replication

The correct solution is the CloudMirror service. CloudMirror is a StorageGRID Platform Service that automatically replicates selected objects from a StorageGRID S3 bucket to an external S3-compatible destination, including Amazon S3. NetApp specifically identifies the use case of mirroring newly ingested customer data into Amazon S3 so that AWS services can perform analytics or other processing on that data.

CloudMirror operates independently of the grid's active ILM policies. After object ingest succeeds, StorageGRID attempts to deliver the replicated object to the configured destination as soon as possible. The tenant configures a Platform Services endpoint containing the destination Amazon S3 bucket information and credentials, then applies a CloudMirror replication configuration to the source bucket.

Option B is incorrect because cross-grid replication is designed for replication between StorageGRID systems connected through grid federation, rather than for using Amazon S3 as an external analytics destination. NetApp XCP and Robocopy are file migration/copy utilities and are not StorageGRID's native event-driven S3 replication mechanism.

Therefore, D. CloudMirror service directly satisfies the requirement to replicate newly ingested StorageGRID objects into Amazon S3 for downstream AWS processing.

Reference topics: Tenant Manager → Platform Services → CloudMirror Replication → Amazon S3 Endpoint → Hybrid Cloud Data Pipelines

Under the legacy strong-global consistency behavior represented by these answer choices, writes use a quorum of metadata replicas at every site, while reads require a quorum of metadata replicas at the local site. Consequently, B and D are the intended answers. This architecture provides read-after-write consistency across all sites while allowing a client to perform reads using the metadata replicas available locally rather than waiting for responses from every remote site. NetApp defines strong-global as guaranteeing read-after-write consistency for client requests across all sites.

There is an important StorageGRID 12.0 qualification. New StorageGRID 12.0 installations use Quorum strong-global semantics by default. In a three-site grid containing three metadata replicas per site, the write requirement becomes a grid-wide quorum of five of the nine metadata replicas, with no more than three replicas contributed by one site. This improves site-failure tolerance. Systems upgraded from StorageGRID 11.9 or earlier retain the legacy strong-global behavior unless explicitly changed.

Therefore, B and D are the certification-key answer for the semantics assumed by this question, but B should not be generalized to a newly installed StorageGRID 12.0 grid using Quorum strong-global.

Reference topics: S3 Consistency → Strong-global → Metadata Replicas → Local Read Quorum → Legacy vs Quorum Strong-global

The correct configuration is to route StorageGRID AutoSupport traffic through an Admin proxy server. NetApp states that when AutoSupport packages are transmitted using HTTPS, the primary Admin Node requires outbound access to NetApp Technical Support either directly or through a proxy server. This is specifically intended for secure environments where StorageGRID nodes cannot establish unrestricted direct internet connections.

The administrator configures this under Configuration > Security > Proxy settings > Admin, enables the Admin proxy, and specifies the proxy server hostname or IP address and port. Authentication credentials can also be supplied when required. Once configured, AutoSupport traffic from Admin Nodes to NetApp Technical Support is routed through this controlled proxy path.

This preserves normal AutoSupport functionality, including periodic and event-triggered AutoSupport packages, which support proactive monitoring and automatic support-case workflows. Manually uploading bundles, as in A, would not provide the desired automated behavior. Option B does not solve the connectivity restriction. Option C is also incorrect because AutoSupport On Demand is intended primarily for active troubleshooting and itself requires HTTPS connectivity; it does not replace normal automated AutoSupport delivery.

Therefore, D provides the required secure outbound connectivity while retaining automated NetApp support capabilities.

Reference topics: Grid Manager → AutoSupport → Admin Proxy → HTTPS AutoSupport → Event-Triggered AutoSupport → NetApp Technical Support Connectivity

StorageGRID Platform Services traffic, including Apache Kafka event notifications, originates from Storage Nodes that run the Administrative Domain Controller (ADC) service. NetApp explicitly requires these ADC Storage Nodes to have network connectivity to external Platform Services endpoints. For Kafka, StorageGRID normally establishes outbound TCP connectivity from ADC Storage Nodes to the Kafka cluster, using port 9092 by default unless another port is configured.

In this topology, the Storage Nodes do not have Client Network interfaces, so they cannot use a Client Network default route to reach the Kafka endpoint. NetApp's supported alternative is to configure the Storage Nodes with Admin Networks containing appropriate Admin External Subnet List (AESL) entries that provide routes to the external endpoint network. Without the required AESL route on the ADC nodes, StorageGRID cannot validate connectivity to the Kafka endpoint.

Option B incorrectly identifies LDR as the service responsible for sending Platform Services messages. Option D is irrelevant because Gateway Nodes do not originate these Kafka Platform Services notifications. Although Platform Services must be enabled for the tenant, the networking details in the scenario specifically identify missing ADC-node endpoint routing as the intended failure.

Reference topics: Platform Services → Kafka Event Notifications → ADC Service → Admin Network → AESL → External Endpoint Connectivity

StorageGRID maintenance should be performed using a rolling, node-by-node approach so that the grid continues providing S3 services while individual nodes are temporarily unavailable. NetApp states that StorageGRID upgrades are designed to be non-disruptive: nodes of the same type are taken down and upgraded one at a time, preventing all nodes of a particular role from becoming unavailable simultaneously.

NetApp also permits administrators to approve individual nodes or groups of nodes and, when upgrade order is important, explicitly recommends waiting for one node or group to complete before approving the next. During this process, administrators should monitor Grid Manager for node status, alerts, and service health.

High availability also depends on appropriate architecture: ILM policies should maintain redundant object copies, and S3 clients should connect through HA-group VIPs, highly available third-party load balancers, or multiple Gateway Nodes.

Option A increases operational risk by scheduling maintenance during peak load. Option C could remove too much grid capacity simultaneously and defeat redundancy. Option D is not a prescribed StorageGRID maintenance procedure and could unnecessarily disrupt grid and client communication.

Reference topics: Software Update → Rolling Upgrade → Hotfix Installation → Node Availability → HA Client Connectivity → ILM Redundancy

For unidirectional cross-grid replication, CGR must be enabled on the bucket in the grid that acts as the source. NetApp states that when CGR is enabled on only one grid, objects added to that source bucket are replicated automatically to the corresponding destination bucket on the other grid; objects written to the destination are not replicated back. Because the required direction is Grid-1 → Grid-2, CGR must therefore be enabled on Grid-1.

The administrator then selects the appropriate grid federation connection and sets Replicate delete markers = Yes. When an S3 client deletes an object without specifying a version ID, StorageGRID creates a delete marker. With this option enabled, that marker is replicated to Grid-2 so the object appears deleted on both grids, helping maintain matching bucket state. NetApp documents this as the default behavior.

Option A would configure bidirectional replication, which violates the unidirectional requirement. Option B reverses the required replication direction. Option D is incorrect because the relevant CGR configuration control is Replicate delete markers, not “Replicate metadata.”

Reference topics: Tenant Manager → Grid Federation → Cross-Grid Replication → Source and Destination Buckets → Versioning → Replicate Delete Markers