Ensuring Successful Operation of a Cloud Solution

Creating a composite index on the status and priority fields is the correct solution for optimizing this Firestore query.

In Firestore, when you query on multiple fields with equality filters (status = 'open' AND priority = 'high'), you need a composite index that includes both fields. Firestore automatically creates single-field indexes for each field, but these are not sufficient for queries that filter on multiple fields. A composite index allows Firestore to efficiently locate documents that match both conditions without having to scan all documents or perform expensive merge operations.

The other options are incorrect for the following reasons:

• Creating separate single-field indexes and letting Firestore merge results is not how Firestore works. Firestore does not automatically merge results from multiple single-field indexes for compound queries. Without a composite index, Firestore will either return an error or perform inefficiently.

• Using a collection group query is designed for querying across subcollections with the same name throughout your database hierarchy. This scenario involves a single top-level collection of tickets, not subcollections, so collection group queries are not applicable here and would not solve the performance issue.

• While restructuring the data model by adding a combined statusPriority field (like 'open_high') could technically work, this is an anti-pattern in Firestore. It introduces data redundancy, increases complexity in data management, and requires updating multiple fields when status or priority changes. The proper solution is to use composite indexes, which is exactly what they are designed for in Firestore.

The correct approach is to create a snapshot schedule policy with daily frequency at 2 AM and 7-day retention, then attach it to the persistent disk.

Google Cloud provides a built-in snapshot schedule feature that allows you to automate disk backups directly through the Console, gcloud CLI, or API. This native solution is the simplest approach because:

1. Snapshot schedules are designed specifically for this use case - automating periodic backups of persistent disks
2. You can specify the exact time (2 AM), frequency (daily), and retention period (7 days) directly in the policy
3. The policy is attached to the persistent disk, which is the correct resource type for snapshot schedules
4. No additional services or custom code are required

The option suggesting Cloud Scheduler with Cloud Functions is unnecessarily complex. While it would technically work, it requires managing multiple services, writing custom code, and handling error scenarios - all of which are already handled by the native snapshot schedule feature.

The option suggesting hourly frequency with 168 snapshots is incorrect and wasteful. The requirement is for daily backups, not hourly. Creating 168 snapshots (24 hours × 7 days) when only 7 are needed is inefficient and increases storage costs unnecessarily.

The option mentioning applying the snapshot schedule to the Compute Engine instance is incorrect because snapshot schedules are attached to persistent disks, not to VM instances. While an instance uses a disk, the snapshot schedule policy must be associated with the disk resource itself, not the instance.

The correct answer is to grant the roles/storage.objectViewer role to the contractor at the bucket level.

The roles/storage.objectViewer role is specifically designed for read-only access to Cloud Storage objects. This role includes the following permissions:
- storage.objects.get (download objects)
- storage.objects.list (list objects in the bucket)

This perfectly matches the requirement where the contractor should only be able to view and download objects without being able to delete, modify, or upload new files.

Why the other options are incorrect:

• The roles/storage.objectAdmin role grants full control over objects, including permissions to create, delete, and modify objects. This violates the principle of least privilege and gives the contractor more access than needed.

• The roles/storage.legacyBucketReader role is a legacy role that was used with fine-grained access control (ACLs). Since the bucket uses uniform bucket-level access, legacy roles should not be used. Additionally, this role provides bucket-level read access which includes listing objects but doesn't properly align with the uniform access model.

• The roles/storage.objectCreator role allows creating (uploading) new objects but does not provide read/download access to existing objects. This is the opposite of what is needed - it would allow the contractor to upload files but not view existing ones.