Knowledge Check - Operations, Resilience, and Performance
Test your understanding of the key concepts from Module 7. Select the best answer for each question, then submit to see your results. You need to score at least 60% to pass.
An architect must give FinCorp's payments-adjacent service an automated failover between two availability zones. The team asks which managed IONOS product orchestrates the failover by watching the primary, declaring it dead, and promoting the secondary across the whole stack. What is the correct answer, and what is the platform's actual automated failover mechanism?
IONOS does not sell a managed failover product that orchestrates promotion across the stack. The native automated mechanism composes the load-balancer plane's health checks, which decide endpoint health within a zone, with a low-TTL Cloud DNS record that is re-pointed to move traffic by manipulating name resolution. Cloud DNS itself is not health-aware. There is no packaged "health-check failover record" wizard in the Cloud DNS console; where the cutover must be automatic at the DNS layer it is driven through the Cloud DNS API. The load balancer forwards only to healthy targets but does not promote a standby stack, and Auto Scaling replaces instances within a tier rather than orchestrating cross-zone failover.
A team places a primary database node and its standby in the same VDC and lets the platform assign availability zones automatically, assuming that an automatically assigned zone gives them multi-zone redundancy. The architect flags this as the auto-zone trap. Why is the assumption wrong, and what is the correct discipline?
Automatic zone assignment is not a multi-AZ guarantee. It can place both members of a redundant pair into the same zone, which means a single zone failure takes out both and the redundancy is illusory. The discipline is to assign explicit, distinct zones to each member of a redundant pair: the standby database node sits in a named zone different from the primary, and pilot-light compute is provisioned to a named zone distinct from the production tier. This is cheap at design time and cannot be cleanly retrofitted after an outage proves the pair was co-located.
FinCorp splits production, non-production, and a compliance-isolated workload across separate contracts, and also runs Managed Kubernetes clusters. The operations team expects a single managed pane that unions all telemetry and expects Kubernetes control-plane events to arrive in the Logging Service alongside application logs. Which statement correctly describes the observability boundaries they must design around?
Monitoring and Logging pipelines are per-contract and per-region, and the Activity Log is per-contract with no aggregation endpoint, so there is no native pane that unions telemetry across separate contracts; aggregation is built by fanning every contract's signal into an external collector. Separately, the "Kubernetes" source in the Logging Service means in-cluster workload and node logs you ship yourself, not the managed control plane; control-plane events are never emitted into the Logging Service pipeline. The cluster's separate "Logging to S3" toggle writes cluster log data to a bucket and is not control-plane visibility in your monitoring pane.
FinCorp's regulated transaction database holds only a few tens of gigabytes of live data, and an engineer proposes provisioning it on a 40 GB SSD volume to match the small data footprint. The architect overrules this. Which reasoning is correct for sizing the volume?
SSD performance scales with volume size up to a cap, accruing per gigabyte, so a small SSD volume starves a demanding workload. The platform recommends booking SSD volumes of at least 100 GB to obtain the full benefit, and for database workloads this roughly 100 GB floor is load-bearing: an SSD volume below it degrades a database tier even when the data set is small. The volume is therefore sized for performance first and capacity second. It is HDD, not SSD, whose performance is flat and independent of volume size, and the Data Center Designer derives predicted performance from the volume's size rather than guaranteeing the ceiling at any size.
FinCorp must migrate a large VMware estate into IONOS. The project plan assumes a native OVF/OVA import wizard for the VMs and a replication-based cutover for the databases moving onto IONOS Managed PostgreSQL. The architect rejects both assumptions. Which description of the correct engineered approach is accurate?
IONOS has no native OVF/OVA import wizard, so migration is engineered, not imported, and the architect chooses one of three honest paths per workload: image conversion and upload onto the KVM Public Cloud surface, VMware-native replication and live failover into dedicated Private Cloud, or backup/restore. On the Private Cloud path a Layer 2 VPN extends a segment across sites so phased waves keep their IP addresses, while live mobility between hosts is intra-cluster only and is never a cross-site live move. The database wave is a dump-and-restore hard cutover with a real downtime window, because there is no native replication-based cutover into the managed databases; the source stays authoritative until the restored target validates.