Certificate Authority Service in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding Certificate Authority Service (CAS) Issuance Behavior

You create a private CA in Google Cloud Certificate Authority Service (CAS) and issue a certificate. What happens if the CA is disabled after issuing the certificate?

A All existing certificates are immediately revoked and become invalid.

B Existing certificates remain valid until their expiration, but no new certificates can be issued.

C The CA automatically renews all existing certificates despite being disabled.

D The CA continues issuing new certificates but marks them as untrusted.

💡 Hint

Think about what disabling a CA means for new and existing certificates.

Disabling a CA stops new certificate issuance but does not affect already issued certificates, which remain valid until they expire or are revoked.

❓ Architecture

intermediate

Designing a Secure CA Hierarchy in Google CAS

You want to design a secure certificate authority hierarchy using Google CAS. Which architecture provides the best security and operational flexibility?

A Create a root CA offline and one or more subordinate CAs online to issue certificates.

B Create a single root CA and use it directly to issue all certificates.

C Create multiple root CAs and issue certificates from all of them directly.

D Use only subordinate CAs without a root CA.

💡 Hint

Consider the role of root and subordinate CAs in security and management.

Using an offline root CA with online subordinate CAs limits exposure of the root key and allows flexible certificate issuance and revocation.

❓ security

advanced

Handling Certificate Revocation in Google CAS

You have issued certificates using Google CAS. Which method does CAS support to notify clients that a certificate is revoked?

A Automatically deleting revoked certificates from client devices.

B Using Online Certificate Status Protocol (OCSP) responses served by CAS.

C Publishing Certificate Revocation Lists (CRLs) that clients check periodically.

D Sending email notifications to clients about revoked certificates.

💡 Hint

Think about standard protocols for certificate revocation notification.

Google CAS publishes CRLs that clients can download and check to verify if a certificate is revoked. OCSP is not currently supported.

❓ Configuration

advanced

Configuring a Private CA with Specific Key Algorithm in Google CAS

You want to create a private CA in Google CAS that uses the ECDSA P-384 key algorithm. Which configuration snippet correctly specifies this?

GCP

private_ca_config = {
  "key_spec": {
    "algorithm": "EC_P384"
  },
  "tier": "ENTERPRISE"
}

A { "key_spec": { "algorithm": "EC_P256_SHA256" }, "tier": "ENTERPRISE" }

B { "key_spec": { "algorithm": "RSA_2048" }, "tier": "ENTERPRISE" }

C { "key_spec": { "algorithm": "EC_P521_SHA512" }, "tier": "ENTERPRISE" }

D { "key_spec": { "algorithm": "EC_P384" }, "tier": "ENTERPRISE" }

💡 Hint

Look for the exact algorithm name for ECDSA P-384 in Google CAS.

The correct algorithm name for ECDSA P-384 is "EC_P384". Other options specify different algorithms.

✅ Best Practice

expert

Best Practice for Protecting Root CA Private Key in Google CAS

What is the best practice to protect the root CA private key in Google Certificate Authority Service?

A Keep the root CA private key offline and only use it to sign subordinate CAs.

B Store the root CA private key in a Google Cloud Storage bucket with restricted access.

C Use the root CA private key directly to issue all end-entity certificates.

D Share the root CA private key with all team members for backup.

💡 Hint

Think about minimizing exposure of the most sensitive key.

Keeping the root CA private key offline reduces risk of compromise. It should only be used to sign subordinate CAs, which handle certificate issuance.