Configuring individual storage systems

Alder Bank writes monthly statement PDFs to a Cloud Storage bucket named stmt-archive in the Standard storage class. Regulations require every statement to be kept for seven years and to be impossible to delete or overwrite during that time, including by project owners. Statements are read often during their first year and almost never afterward, and the bank wants to minimize storage cost.

Which two actions should you perform? Each correct answer presents part of the solution.

1. ASet a seven-year retention policy on stmt-archive and lock itA retention policy prevents deletion or replacement of objects until they reach the retention period, and locking it makes the policy permanent so that no one can remove or shorten it.
2. BAdd an Object Lifecycle Management rule that changes objects to the Archive storage class when they reach an age of 365 daysA SetStorageClass lifecycle action moves rarely read statements to Archive after the first year, lowering storage cost while the retention policy keeps them protected.
3. CEnable Object Versioning on stmt-archiveVersioning keeps noncurrent copies when objects are overwritten, but users with sufficient permissions can still delete those versions, so it does not enforce retention.
4. DSet the bucket's default storage class to ArchiveWriting new statements directly to Archive would incur higher retrieval costs during the first year, when the statements are read often.
5. EPlace a temporary hold on each statement when it is uploadedHolds must be applied per object and can be released by anyone with the right permission, so they do not provide a guaranteed, owner-proof seven-year retention.

Granite Peak Genomics must move a 300 TB archive of sequencing files from its on-premises NAS to Cloud Storage within four weeks to meet a grant deadline. The site's only internet link is 1 Gbps, and no more than half of it can be used for the transfer during business operations. There is no plan to increase bandwidth.

Which transfer method should you recommend?

1. AStorage Transfer Service with transfer agents installed on servers that mount the NASAgent-based Storage Transfer Service is the right tool for large online transfers, but it is still limited by the 500 Mbps available, which needs roughly eight weeks for 300 TB.
2. BThe gcloud storage cp command with parallel composite uploads from several serversParallelism improves use of available bandwidth but cannot exceed the network limit, so the transfer still takes well over four weeks.
3. COrder a 10 Gbps Partner Interconnect connection and run the transfer over itThe scenario rules out adding bandwidth, and provisioning a new interconnect involves a provider order and lead time that would consume much of the four-week window.
4. DTransfer Appliance, loaded on-premises and shipped to Google for upload to Cloud StorageTransfer Appliance moves large datasets offline when network transfer would take too long, so the 300 TB arrives in Cloud Storage without depending on the constrained link.

Kestrel Outfitters runs its order system on a Cloud SQL for MySQL Enterprise edition instance named orders-db with high availability, automated daily backups at 02:00, and point-in-time recovery enabled. At 14:05 a developer accidentally dropped the order_items table. The business wants to recover the table with as little data loss as possible and without overwriting orders that arrived after 14:05 in other tables.

What should you do?

1. ARestore the 02:00 automated backup onto orders-dbRestoring the daily backup over the instance loses about 12 hours of changes in every table and overwrites the orders received after the incident.
2. BUse point-in-time recovery to create a new instance at 14:04, then export order_items from it and import the table into orders-dbPoint-in-time recovery creates a new instance from the backup and replays logs to just before the drop, so the table can be copied back while orders-db keeps all later changes.
3. CTrigger a manual failover of orders-db to its standby instanceThe HA standby is kept synchronously in step with the primary, so the drop has already been applied there; failover protects against zone failure, not user error.
4. DPromote a cross-region read replica of orders-dbA read replica replicates the DROP TABLE statement within seconds, so promoting it gives a copy that is also missing the table.

Juniper Clinics runs its scheduling application on a Cloud SQL for PostgreSQL instance named sched-db with 500 GB of SSD storage. The database grows unpredictably, and last month it ran out of disk during a month-end batch, which caused an outage. The operations team wants to prevent this from recurring without manual monitoring or resizing.

What should you do?

1. AEnable automatic storage increase on sched-dbAutomatic storage increase checks available space and adds capacity when the instance nears its limit, so growth no longer causes an out-of-space outage.
2. BCreate a read replica of sched-db and send the batch queries to itA read replica offloads read traffic, but it holds a full copy of the data and does nothing to add storage to the primary instance.
3. CMigrate sched-db to a larger machine type with more vCPUs and memoryMachine type controls CPU and memory; storage capacity is configured separately, so a larger machine does not prevent running out of disk.
4. DSchedule a monthly job that doubles the storage size of sched-db and later shrinks itCloud SQL storage can be increased but never decreased, so a grow-and-shrink plan is not possible and would leave the instance permanently overprovisioned.