D. gcloud privateca revoke my-cert --location=us-central1
Solution
Step 1: Identify command for self-signed root CA creation
The command gcloud privateca roots create is used to create a self-signed root certificate authority.
Step 2: Verify other options
gcloud privateca subordinate create my-sub --subject="CN=My Sub CA" --location=us-central1 creates a subordinate CA, C creates a certificate, and D revokes a certificate, so they are incorrect for creating a self-signed CA.
But got an error about missing permissions. What is the most likely cause?
medium
A. You do not have the required IAM role to create subordinate CAs
B. The command syntax is incorrect; 'subordinate create' is invalid
C. The location 'us-central1' does not support subordinate CAs
D. The issuer 'my-root' does not exist in the project
Solution
Step 1: Understand permission errors
Permission errors usually mean the user lacks the required IAM role or permission to perform the action.
Step 2: Check command validity and other options
The command syntax is valid, 'us-central1' supports subordinate CAs, and issuer existence errors usually mention not found, not permissions.
Final Answer:
You do not have the required IAM role to create subordinate CAs -> Option A
Quick Check:
Permission error = missing IAM role [OK]
Hint: Permission errors usually mean missing IAM role [OK]
Common Mistakes:
Assuming syntax error causes permission issues
Ignoring IAM roles and permissions
Confusing location support with permission problems
5. You want to set up a secure internal network where your services trust certificates issued by your own CA. Which steps should you follow using Certificate Authority Service to achieve this?
hard
A. Create multiple root CAs and assign each service a different root CA
B. Create only a self-signed root CA and issue certificates directly from it to services
C. Use Google-managed CA and import your certificates manually to services
D. Create a root CA, create a subordinate CA signed by the root, then issue certificates from the subordinate CA to services
Solution
Step 1: Understand best practice for internal CA hierarchy
Best practice is to create a root CA and then a subordinate CA signed by the root to issue certificates, improving security and manageability.
Step 2: Evaluate options
Create only a self-signed root CA and issue certificates directly from it to services is less secure because issuing directly from root CA is discouraged. Use Google-managed CA and import your certificates manually to services uses Google-managed CA, not your own. Create multiple root CAs and assign each service a different root CA creates unnecessary complexity.
Final Answer:
Create a root CA, create a subordinate CA signed by the root, then issue certificates from the subordinate CA to services -> Option D
Quick Check:
Root CA + subordinate CA hierarchy = secure internal trust [OK]
Hint: Use root CA + subordinate CA for secure internal certificates [OK]
Common Mistakes:
Issuing certificates directly from root CA
Using Google-managed CA instead of own CA
Creating multiple root CAs unnecessarily
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.