Knowledge Check - Governance, Identity, and Cost
Test your understanding of the key concepts from Module 2. Select the best answer for each question, then submit to see your results. You need to score at least 60% to pass.
FinCorp wants to separate its non-production environment from production purely so each shows as its own line on the monthly bill, while keeping one governance and audit realm. The architect is asked whether this needs a second contract. What is the correct guidance?
A VDC is the regional and environmental segmentation primitive inside a contract, and each VDC already produces its own section on the monthly bill. Cost visibility alone therefore does not justify a second contract, which is the commercial, governance, and audit boundary. A new contract is warranted only for compliance isolation, a different owner or legal entity, or a separate audit scope.
An architect pins FinCorp's first regulated VDC to a German region and later realises a different German region would have been preferable. What is the reality of changing it?
A VDC's region is fixed at creation. Reserved IPv4 blocks are usable only in the region where they were reserved, and images and snapshots are region-local with no managed cross-region replication. Because these region-bound attributes cannot follow the VDC elsewhere, the region (and the name) is a one-way decision, which is why placement is settled deliberately and once.
A FinCorp auditor needs to review activity but must not be able to change any infrastructure. The platform has no deny rule. How should the architect grant this access?
Access is group-based with capability rights and resource grants kept separate, read is implicit when a resource is granted, and there is no deny rule. Least privilege is therefore achieved by granting only what the role needs: the Access Activity Log capability and Read-level resource grants. An over-broad grant cannot be patched with an exception because no deny exists; it would have to be removed and re-scoped.
FinCorp runs a corporate identity provider and wants to federate IONOS access so that joiners are created and assigned groups automatically on first login. What must the architect tell the team?
IONOS federation supports SAML 2.0 and OIDC but its scope today is authentication only. There is no just-in-time provisioning (the user must pre-exist), and the IdP does not drive IONOS group membership (access mapping is on the roadmap, not available). Federation verifies the person; the group-and-grant model still governs what they may do, so the lifecycle is an explicit manual runbook.
FinCorp will run a steady baseline of dedicated-core compute for at least three years but expects occasional bursts well above it. The architect is sizing a Savings Plan. Which approach is correct?
A Savings Plan is a resource-based commitment with a 15% discount at 1-year and 40% at 3-year on dedicated cores and RAM. Usage above the committed quantity bills at the standard PAYG rate (overflow is not rejected), and the plan cannot be edited after activation or cancelled. The safe discipline is to commit only the floor you are certain to run for the term and leave variable bursts on flexible PAYG, rather than locking in optimistic peak spend that cannot later be reduced.