5.8 Knowledge Check - Data and Storage

1.

FinCorp's customer portal serves account-summary and transaction-history views that are read far more often than they are written, all from a regulated Managed PostgreSQL cluster on the private data tier. An architect proposes adding read replicas to that cluster and pointing reporting traffic at a standby. Why is this the wrong starting point, and what is the native pattern?

A Standbys can serve reads, but only in strictly-synchronous replication mode, so the cluster must first be switched to that mode before reporting traffic is routed to a standby. B Managed PostgreSQL has no read replicas and standbys exist only for failover, so read scaling comes from an In-Memory DB cache tier placed in front of the cluster, with a managed connection pooler to multiplex connections. C Read replicas exist but are capped at the cluster's one-to-five instance count, so the architect should provision the maximum five standbys and load-balance reads across them. D Reporting traffic should be served from a Block Storage snapshot of the database volume, restored into a second read-only cluster on a schedule.

2.

An architect is designing data continuity for FinCorp's estate, which includes migrated VMs, Block Storage volumes, a Managed PostgreSQL cluster, and a Managed MongoDB cluster. A teammate proposes a single plan: install the Acronis-based Backup Service agent everywhere, including on the database hosts, so one console covers the whole estate. What is the decisive flaw?

A The Backup Service cannot protect on-premises or other-cloud VMs, so it cannot serve a hybrid estate during migration. B The Backup Service provides immutable backups by default, which would conflict with the lifecycle expiry the databases require. C The Backup Service can protect the databases, but only if each database volume is first converted to DAS NVMe storage. D The Backup Service covers VMs and Block Storage but explicitly does not back up managed databases, so the PostgreSQL and MongoDB clusters need their own native continuity (PITR plus logical dump/restore to Object Storage) rather than a backup agent.

3.

FinCorp must keep its multi-year audit archive in Object Storage as tamper-evident, write-once retention that not even a contract administrator can shorten or delete before the retention date. The architect provisions a contract-owned bucket in a German region, uploads the first exports, and then tries to enable Object Lock in COMPLIANCE mode. The console offers no option to turn it on. What went wrong, and what is the correct design?

A Object Lock can only be enabled when the bucket is created, never added afterward, so the archive must go in a new bucket created with Object Lock in COMPLIANCE mode from the start. B COMPLIANCE mode is API-only, so the lock must be enabled through the S3 API rather than the Data Center Designer, but it can still be added to the existing bucket. C Object Lock requires versioning to be disabled first; once versioning is turned off, COMPLIANCE mode becomes available on the existing bucket. D GOVERNANCE mode must be enabled before COMPLIANCE mode can be selected, so the architect should set GOVERNANCE on the existing bucket and then upgrade it.

4.

FinCorp's high-volume transaction feed flows through Event Streams for Apache Kafka. The requirement is that all events for a given account are processed in the order they occurred, while different accounts are processed concurrently, and that partitions distribute evenly across the cluster's three brokers. Which topic design satisfies all three constraints at once?

A Create the topic with a single partition so global ordering is guaranteed, then run many consumers in one group to gain parallelism across accounts. B Create the topic with 5 partitions and rely on round-robin production, accepting that ordering holds per topic rather than per account. C Set a partition key on the account identifier and start at 3 partitions (a multiple of the three brokers), scaling to 6 or 9 only when measured throughput justifies it, sized up front because adding partitions later rehashes keys and breaks per-key ordering. D Create the topic with as many partitions as expected peak consumers regardless of broker count, since more partitions always improve throughput without a downside.

5.

FinCorp's managed databases do not expose a change-data-capture stream that downstream systems can subscribe to, yet the analytics warehouse, the fraud model, and a search index all need to react to every change. The architecture must also let the AI tier re-read the change history from a committed position when a model is retrained. Which approach is the native substitute on IONOS?

A Tail the PostgreSQL Write-Ahead Log directly from each downstream consumer, since the WAL is the platform's built-in change stream. B Schedule a periodic logical dump of the database to Object Storage and have each downstream system diff successive dumps to detect changes. C Enable MongoDB managed change-stream replication to a second cluster and point the warehouse, fraud model, and search index at that replica. D Have the application publish a domain event to a Kafka topic at the moment it makes each change, with each downstream system consuming the topic as an independent consumer group reading from its own committed offset.

6.

FinCorp needs a tamper-evident, long-horizon copy of its Managed PostgreSQL data that survives outside the cluster and can be retained for years, separate from the cluster's own 7-day point-in-time recovery window. Which composition meets this while respecting the platform's boundaries?

A Extend the PostgreSQL PITR retention to its maximum and treat the cluster's immutable backup store as the long-term, portable archive. B Take scheduled logical dumps with pg_dump and land them in an Object Storage bucket with object lock in COMPLIANCE mode, since PITR is window-bound and tied to the cluster while a dump is a portable, version-tolerant copy and object lock supplies tamper-evidence. C Take regular Block Storage snapshots of the database volume and copy them to Object Storage, relying on the snapshots as the database-consistent long-term backup. D Direct the Backup Service agent at the database host and send its output to an object-locked bucket for the long-horizon copy.