Knowledge Check - Best-Practice Architecture
Test your understanding of the key concepts from Module 8. Select the best answer for each question, then submit to see your results. You need to score at least 60% to pass.
A FinCorp tier must scale out automatically under variable load. An architect configures a VM Auto Scaling group with a scale-out threshold at 70% CPU and a scale-in threshold at 50% CPU, expecting the 20-point band to hold the group steady. The platform rejects the policy. Which rule has been violated, and what is the correct design principle?
VM Auto Scaling enforces a mandatory minimum 40-percentage-point separation between the scale-in and scale-out thresholds. This dead band is the primary anti-flapping control: without it, a noisy reading could cross both thresholds in quick succession and drive the group to scale out then immediately back in. A 20-point gap is below the floor and is rejected. The service supports five metrics (CPU utilisation average and incoming/outgoing network bytes and packets), so the metric choice is not the problem, and the scale-out threshold is correctly above the scale-in threshold.
An architect has produced a functionally complete design for FinCorp's regulated containerised processing, running it on Managed Kubernetes, and now applies the sovereignty and attestation filter. The workload contractually requires BSI C5 coverage. What does the filter reveal, and what is the correct conclusion?
This is the second composition error: a functionally correct choice placed outside the required attestation scope. The filter is applied last, over a design that is already functionally complete, because compliance narrows choices rather than originating them. C5 covers exactly Compute Engine, Cloud Cubes, and Object Storage; Managed Kubernetes is in the IT-Grundschutz scope but not in C5, and the two scopes are not interchangeable. A workload that contractually requires C5 therefore moves onto a C5-covered service such as Compute Engine. The choice was not wrong technically; it was wrong against the scope filter, and a held attestation never licenses a platform-wide claim.
In the reference architecture, the request path is deliberately layered: a public balancer at the edge and a private balancer in front of the data tier. An engineer proposes a single Layer 4 NLB at both positions to standardise, and proposes wrapping each managed balancer in a Network Security Group for filtering. Why does the reference design reject both proposals?
The two balancer altitudes exist for two different reasons. The public Layer 7 ALB terminates TLS and routes on content where routing logic matters; the private Layer 4 NLB passes TCP through quickly where it does not, leaving the certificate on the backend. Standardising on one layer discards the reason each was chosen. Separately, neither managed balancer accepts a Network Security Group or an IP allowlist, so attaching an NSG to a managed balancer does nothing; filtering belongs on the target NICs, and the data tier's safety comes from living on a private LAN rather than from a balancer-level firewall. DNS steers new connections but is not a load balancer and applies no NSG, and Cloud DNS has no native health-check-based failover.
The capstone build stitches the per-module pieces into one VDC. A team provisions resources in this order: they create the private Layer 4 NLB, then the data-tier servers it should serve, then a NAT Gateway, and they expect private workloads to reach the internet as soon as the NAT Gateway exists. Which assessment of their sequence is correct?
An integrated build is a dependency graph resolved bottom-up, not a checklist the platform reorders. A Layer 4 NLB pointed at targets that do not yet exist has nothing to route, so the data-tier servers must be provisioned before the NLB is created. The NAT Gateway, even with a reserved public IP and a SNAT rule, produces no egress until the private LAN's default route (0.0.0.0/0) is repointed at it; that routing change is the step teams forget, and the platform does not make it automatically. The correct order across the whole build is network substrate, then compute, then the data tier, then the balancers, then the container platform, then the hybrid edge.
FinCorp's auditor asks the architect to show, service by service, which BSI recognition covers each component of the deployed design. The architect must answer precisely rather than claiming the platform is certified. Which statement reflects the correct service-by-service compliance mapping?
Compliance on IONOS is scoped per service and per German data-center location, never platform-wide, so the answer must name the service, the credential, and the location rather than asserting a blanket certification. C5 (a Type 1 attestation) covers exactly Compute Engine, Cloud Cubes, and Object Storage. IT-Grundschutz (an ISO 27001 certificate) covers exactly Compute Engine, Object Storage, Backup, and Managed Kubernetes. The two scopes diverge: Cubes are in C5 but not IT-Grundschutz, while Managed Kubernetes and Backup are in IT-Grundschutz but not C5. The relational and cache engines and the managed balancers sit in neither, and the regulated dedicated VMware core is scoped to its own attestations rather than to platform C5.