Blueprint Deployment Blocked by a Quota That Does Not Match the Math
A Calm project 'Payments-Dev' has a quota of 20 vCPUs and 48 GB memory. A blueprint has two app profiles: 'dev' deploys one 4-vCPU/16-GB web VM and one 4-vCPU/16-GB DB VM; 'prod' deploys three web VMs and one DB VM, each 4 vCPU/16 GB. The project currently has one running dev deployment consuming 8 vCPU/32 GB. A developer launches a second dev deployment; it fails at the DB task with 'quota exceeded'. The developer insists the math is 16 vCPU/64 GB, which fits. Meanwhile, a production launch by the project manager is stuck in 'Pending Approval' for 90 minutes, and an operator cannot see the 'Payments-Dev' project in the self-service catalog. The blueprint uses the macro @@{AppProfile}-db in the VM name and a credential named 'payments-svc'.
1. The developer's math appears to fit the vCPU quota. Explain why the second dev deployment still failed at the DB task, and what cleanup/verification steps you would take.
Read the worked answer
Quota is enforced per project across all deployments, not per blueprint launch. With 20 vCPU and 48 GB memory, the existing dev deployment consumes 8 vCPU/32 GB. The new dev profile needs 8 vCPU/32 GB. After the web VM is created, the project is at 12 vCPU/48 GB. The DB VM needs another 4 vCPU/16 GB, which would total 16 vCPU/64 GB. That exceeds the 48-GB memory quota even though 16 vCPU fits under 20. The failure occurs at the DB task because Calm creates resources in order and checks quota as it goes; the deployment is partially built. The developer compared only vCPU.
Verify current quota consumption in the project, not just the running app list. Delete or resize the partial deployment so it does not hold quota, then either raise the project memory quota, reduce the profile's memory, or remove an old deployment. Also check whether a pending production approval will consume quota when approved, and confirm the project's storage quota is not the next blocker.
2. The VM name uses the macro `@@{AppProfile}-db`. What should you check about macro resolution and naming before retrying, and why does it matter for a second deployment?
Read the worked answer
Calm resolves @@{AppProfile} at launch from the selected app profile, so the first dev deployment creates a VM named dev-db. A second dev deployment in the same project will resolve to the same dev-db unless the name includes a deployment-unique component. Depending on the project's naming rules, that can cause a conflict, an overwrite, or a failed task, and it makes post-failure cleanup ambiguous because two deployments appear to own the same name.
Check the resolved variables in the deployment's launch and audit details, not just the blueprint text. Add a unique macro such as the application or deployment name to the VM name, and confirm the resulting name is within the platform's length and character limits. Also confirm the payments-svc credential exists in the project and environment and has permission to create and modify VMs. Fix naming before retrying; otherwise a successful retry may still collide or leave orphaned resources.
3. The production launch has been pending approval for 90 minutes, and an operator cannot see the project in the catalog. What are the likely causes and how do you confirm each?
Read the worked answer
Pending approval means the deployment passed validation and is waiting on an approver, not that it is broken. Likely causes: the prod app profile has an approval policy; the designated approvers are unavailable or not notified; the approver lacks the project-scoped approval permission; or the request is waiting on a group that has no members. Confirm in the deployment's approval and audit record who the approver set is and whether notifications were sent.
For the operator, project visibility requires both project membership or role assignment and a published catalog item. The operator may be in the AD group but the group sync has not completed, the role may be scoped to a different project, or the blueprint may not be published to the operator's project catalog. Confirm by checking the operator's effective role on the project, group membership, and catalog publication. Do not fix this by granting Prism Central admin; grant the minimum project role and republish the blueprint if needed.