ISC2 Certified Cloud Security Professional (CCSP) Practice Question

Your organization uses an external CI/CD system to deploy virtual networks in its public IaaS tenant. Security policy states:

The pipeline may modify only resources that belong to the development project.
Any API call that creates an Internet-facing gateway must be approved by an administrator before it is executed.
The pipeline must not store long-lived cloud API keys; credentials have to rotate automatically without code changes.

Which management-plane design best satisfies all three requirements?

Configure the pipeline to authenticate with each engineer's multifactor-protected personal account and rely on peer code reviews to prevent unauthorized gateway creation.
Create a dedicated service identity with only network-management rights in the development project, require privileged-access approval for the create-gateway API action, and have the CI/CD job obtain short-lived tokens from the cloud provider's automatic credential rotation service at run time.
Store the cloud tenant's global administrator access key in the CI/CD secret vault and rely on perimeter firewalls to block unauthorized Internet-gateway creation requests.
Use a shared SSH key so the pipeline can log into a bastion host and run CLI commands interactively whenever network changes, including gateway creation, are required.

Report Issue

Answer Description

The most effective way to meet every requirement is to give the CI/CD platform its own cloud service identity (often called a service principal, service account, or role) that has narrowly scoped, least-privilege permissions-only what is needed to manage networking objects in the development project. The provider's privileged-access or just-in-time (JIT) feature can enforce human approval for sensitive actions such as creating Internet gateways. Finally, supplying the pipeline with short-lived, automatically rotated tokens obtained on demand (for example, via the cloud provider's secure token or managed-identity service) eliminates any need to embed long-term static keys.

The other options fail at least one requirement:

A global administrator key violates least-privilege and still uses a long-lived secret.
Using individual developer logins may satisfy short-lived credentials but breaks the automation requirement and gives broader rights than necessary, while code reviews are not an enforced approval on the management plane.
A shared SSH key to a jump host neither scopes access to the dev project nor avoids long-lived credentials, and it does not provide explicit approval workflows for sensitive API calls.

Ask Bash

Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.