Your enterprise platform team is preparing to migrate several multi-tenant custom domains (including wildcard domains) to a global External Application Load Balancer. You are designing an automated CI/CD deployment pipeline using Google Cloud Certificate Manager to manage public SSL/TLS certificates. You have the following operational requirements: Certificates must be fully provisioned, validated, and active prior to shifting public production traffic to prevent TLS handshake errors and downtime. Domain ownership validation must support wildcard domains and domains whose live DNS A/AAAA records still point to legacy infrastructure. Certificates and domain routing must scale dynamically beyond standard target proxy certificate limits and support automated zero-downtime renewals. Which workflow should you implement in your automated deployment pipeline to satisfy these requirements?

Create Certificate Manager DNS authorizations, publish the generated CNAME challenge records to the authoritative DNS provider, provision Google-managed certificates referencing these DNS authorizations, map the certificates to domain entries within a Certificate Map, and attach the Certificate Map to the target HTTPS proxy.: What Certificate Manager DNS Authorization and Certificate Maps Are Google Cloud Certificate Manager is a dedicated service designed to centrally manage, provision, and bind public and private SSL/TLS certificates to Google Cloud load balancers. It replaces traditional target proxy certificate lists by introducing Certificate Maps and DNS Authorizations, enabling automated zero-downtime certificate lifecycle management and scaling to hundreds of thousands of domain certificates. How it meets the requirements Pre-provisioning and zero downtime: Creating DNS authorizations allows domain control validation (DCV) to complete via DNS CNAME challenge records before cutting over production traffic. This ensures that Google-managed certificates are issued, verified, and in an ACTIVE state before modifying customer-facing DNS records. Wildcard and legacy traffic support: DNS authorization is mandatory for validating wildcard domains (e.g., *.example.com) and allows provisioning certificates for domains currently serving live traffic on third-party infrastructure without requiring downtime or temporary HTTP routing. Scalability via Certificate Maps: Using a Certificate Map with granular Certificate Map Entries allows decoupling certificate associations from the target HTTPS proxy, bypassing legacy quotas (such as the target proxy limit of 15 certificates) and automating continuous certificate renewals without redeploying the load balancer. Key advantages and capabilities Automated Renewals: Certificate Manager automatically tracks certificate expiration and renews certificates using the established DNS authorization challenge records without administrator intervention. High Capacity: Supports up to hundreds of thousands of certificates per load balancer using map entries. Decoupled Architecture: Enables infrastructure-as-code CI/CD pipelines to independently manage DNS authorizations, certificates, and mapping entries without modifying proxy configurations. Why this is optimal This sequence guarantees that certificates are valid and active prior to DNS cutover, fully supports wildcard domain validation, and leverages modern Certificate Maps attached to the Target HTTPS Proxy for automated renewals and maximum scalability.

Pre-Provision Wildcard Certificates with Certificate Maps

Pre-provisioning Wildcard Certificates with DNS Authorization and Certificate Maps

Your enterprise platform team is preparing to migrate several multi-tenant custom domains (including wildcard domains) to a global External Application Load Balancer. You are designing an automated CI/CD deployment pipeline using Google Cloud Certificate Manager to manage public SSL/TLS certificates.

You have the following operational requirements:

Certificates must be fully provisioned, validated, and active prior to shifting public production traffic to prevent TLS handshake errors and downtime.
Domain ownership validation must support wildcard domains and domains whose live DNS A/AAAA records still point to legacy infrastructure.
Certificates and domain routing must scale dynamically beyond standard target proxy certificate limits and support automated zero-downtime renewals.

Which workflow should you implement in your automated deployment pipeline to satisfy these requirements?

Create a global Certificate Map with fallback wildcards, attach the map to the forwarding rule, and configure Cloud DNS peering to automatically issue Google-managed certificates without external DNS records.

Generate self-signed fallback certificates, attach them to the Target SSL Proxy, and configure a Cloud Run job in the CI/CD pipeline to query Let's Encrypt ACME APIs to upload and rotate renewed certificates via Secret Manager.

Create Load Balancer-managed certificates referencing HTTP authorizations, deploy a URL map path-matcher rule forwarding /.well-known/acme-challenge/ to a backend bucket, attach the certificates directly to the target HTTPS proxy, and shift DNS A records to trigger validation.

Create Certificate Manager DNS authorizations, publish the generated CNAME challenge records to the authoritative DNS provider, provision Google-managed certificates referencing these DNS authorizations, map the certificates to domain entries within a Certificate Map, and attach the Certificate Map to the target HTTPS proxy.

Explanations

Create a global Certificate Map with fallback wildcards, attach the map to the forwarding rule, and configure Cloud DNS peering to automatically issue Google-managed certificates without external DNS records.

What this architectural configuration proposes

This option suggests attaching a Certificate Map directly to a Global Forwarding Rule and attempting to bypass public domain validation by creating a Cloud DNS peering zone.

Why it doesn't meet the requirements

Invalid Target Attachment: In Google Cloud networking, Certificate Maps are attached to the Target HTTPS Proxy (--certificate-map), not to the Forwarding Rule. Forwarding rules only specify the IP address, port, and reference the target proxy.
Invalid Public CA Validation: Cloud DNS peering is a private routing construct within Google Cloud VPCs. Public Certificate Authorities (such as Google Trust Services) cannot validate ownership of public custom domains through internal DNS peering; they require publicly resolvable DNS CNAME records or public HTTP verification.
Failure to Automate Lifecycle: Without valid public DNS challenge records, Certificate Manager cannot issue or automatically renew public certificates.

Key characteristics and limitations

Forwarding rules cannot accept certificate map attachments.
Cloud DNS peering does not satisfy public ACME/DCV domain ownership requirements.
Produces deployment validation errors during Terraform/API execution.

This answer would be correct if

You were configuring private service access across internal VPC networks with a private Certificate Authority Service (CAS) instance rather than public SSL/TLS for external customer domains.

View source documentation

Generate self-signed fallback certificates, attach them to the Target SSL Proxy, and configure a Cloud Run job in the CI/CD pipeline to query Let's Encrypt ACME APIs to upload and rotate renewed certificates via Secret Manager.

What custom ACME rotation with Secret Manager is

This pattern relies on custom scripts running on Cloud Run or Compute Engine to interact directly with an ACME certificate authority (such as Let's Encrypt), storing the resulting private keys and certificates inside Secret Manager, and updating the load balancer via custom automation.

Why it doesn't meet the requirements

Target SSL Proxy Mismatch: External Application Load Balancers (Layer 7 HTTP/HTTPS) require a Target HTTPS Proxy, not a Target SSL Proxy (which is strictly used for Layer 4 TCP proxy load balancing).
High Maintenance & Operational Overhead: Building custom ACME integration and renewal scripts creates unnecessary operational complexity, failure modes, and security overhead compared to using native Certificate Manager.
Self-signed Fallback Issues: Self-signed certificates cause severe browser security warnings and SSL handshake termination errors during the initial cutover phase before ACME issuance completes.

Key characteristics and limitations

Introduces complex secret rotation logic in the CI/CD pipeline.
Relies on non-native tooling rather than fully managed Google Cloud services.
Target SSL proxies do not support HTTP/HTTPS layer-7 routing rules, host matching, or Certificate Maps.

This answer would be correct if

You were building a Layer 4 TCP proxy service requiring custom mutual TLS (mTLS) or handling legacy protocols that cannot utilize Google Cloud managed Certificate Manager automation.

View source documentation

Create Load Balancer-managed certificates referencing HTTP authorizations, deploy a URL map path-matcher rule forwarding `/.well-known/acme-challenge/` to a backend bucket, attach the certificates directly to the target HTTPS proxy, and shift DNS A records to trigger validation.

What HTTP-based validation and direct Target HTTPS Proxy attachment is

This approach uses standard Load Balancer-managed SSL certificates (Compute Engine managed certificates) or HTTP domain verification, relying on direct attachment of certificate resources to the load balancer's Target HTTPS Proxy and resolving HTTP challenge tokens over port 80.

Why it doesn't meet the requirements

Fails Wildcard Support: Public Certificate Authorities (such as Let's Encrypt or Google Trust Services) do not permit HTTP-01 or HTTP-based challenge tokens for wildcard domains; wildcard verification strictly requires DNS-01 / DNS-based authorization.
Pre-provisioning Failure & Downtime Risk: HTTP validation requires the domain's public DNS A/AAAA records to route to the load balancer before the certificate can be validated and issued. Switching DNS to an uncertified endpoint results in immediate TLS handshake failures and customer downtime during the provisioning window.
Scalability Limitations: Direct target HTTPS proxy attachment is constrained by strict resource quotas (maximum 15 SSL certificates per target proxy), failing enterprise multi-tenant scale requirements.

Key characteristics and limitations

Lacks support for pre-validation before DNS traffic cutover.
Incapable of issuing wildcard certificates.
Subject to target HTTPS proxy certificate limits.

This answer would be correct if

You were provisioning a single, non-wildcard domain where the DNS had already been pointed to Google Cloud and advanced Certificate Manager map structures were not required.

View source documentation

Create Certificate Manager DNS authorizations, publish the generated CNAME challenge records to the authoritative DNS provider, provision Google-managed certificates referencing these DNS authorizations, map the certificates to domain entries within a Certificate Map, and attach the Certificate Map to the target HTTPS proxy.

What Certificate Manager DNS Authorization and Certificate Maps Are

Google Cloud Certificate Manager is a dedicated service designed to centrally manage, provision, and bind public and private SSL/TLS certificates to Google Cloud load balancers. It replaces traditional target proxy certificate lists by introducing Certificate Maps and DNS Authorizations, enabling automated zero-downtime certificate lifecycle management and scaling to hundreds of thousands of domain certificates.

How it meets the requirements

Pre-provisioning and zero downtime: Creating DNS authorizations allows domain control validation (DCV) to complete via DNS CNAME challenge records before cutting over production traffic. This ensures that Google-managed certificates are issued, verified, and in an ACTIVE state before modifying customer-facing DNS records.
Wildcard and legacy traffic support: DNS authorization is mandatory for validating wildcard domains (e.g., *.example.com) and allows provisioning certificates for domains currently serving live traffic on third-party infrastructure without requiring downtime or temporary HTTP routing.
Scalability via Certificate Maps: Using a Certificate Map with granular Certificate Map Entries allows decoupling certificate associations from the target HTTPS proxy, bypassing legacy quotas (such as the target proxy limit of 15 certificates) and automating continuous certificate renewals without redeploying the load balancer.

Key advantages and capabilities

Automated Renewals: Certificate Manager automatically tracks certificate expiration and renews certificates using the established DNS authorization challenge records without administrator intervention.
High Capacity: Supports up to hundreds of thousands of certificates per load balancer using map entries.
Decoupled Architecture: Enables infrastructure-as-code CI/CD pipelines to independently manage DNS authorizations, certificates, and mapping entries without modifying proxy configurations.

Why this is optimal

This sequence guarantees that certificates are valid and active prior to DNS cutover, fully supports wildcard domain validation, and leverages modern Certificate Maps attached to the Target HTTPS Proxy for automated renewals and maximum scalability.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Pre-provisioning Wildcard Certificates with DNS Authorization and Certificate Maps

You have the following operational requirements:

Certificates must be fully provisioned, validated, and active prior to shifting public production traffic to prevent TLS handshake errors and downtime.
Domain ownership validation must support wildcard domains and domains whose live DNS A/AAAA records still point to legacy infrastructure.
Certificates and domain routing must scale dynamically beyond standard target proxy certificate limits and support automated zero-downtime renewals.

Which workflow should you implement in your automated deployment pipeline to satisfy these requirements?

Explanations

Create a global Certificate Map with fallback wildcards, attach the map to the forwarding rule, and configure Cloud DNS peering to automatically issue Google-managed certificates without external DNS records.

What this architectural configuration proposes

This option suggests attaching a Certificate Map directly to a Global Forwarding Rule and attempting to bypass public domain validation by creating a Cloud DNS peering zone.

Why it doesn't meet the requirements

Invalid Target Attachment: In Google Cloud networking, Certificate Maps are attached to the Target HTTPS Proxy (--certificate-map), not to the Forwarding Rule. Forwarding rules only specify the IP address, port, and reference the target proxy.
Invalid Public CA Validation: Cloud DNS peering is a private routing construct within Google Cloud VPCs. Public Certificate Authorities (such as Google Trust Services) cannot validate ownership of public custom domains through internal DNS peering; they require publicly resolvable DNS CNAME records or public HTTP verification.
Failure to Automate Lifecycle: Without valid public DNS challenge records, Certificate Manager cannot issue or automatically renew public certificates.

Key characteristics and limitations

Forwarding rules cannot accept certificate map attachments.
Cloud DNS peering does not satisfy public ACME/DCV domain ownership requirements.
Produces deployment validation errors during Terraform/API execution.

This answer would be correct if

You were configuring private service access across internal VPC networks with a private Certificate Authority Service (CAS) instance rather than public SSL/TLS for external customer domains.

View source documentation

Generate self-signed fallback certificates, attach them to the Target SSL Proxy, and configure a Cloud Run job in the CI/CD pipeline to query Let's Encrypt ACME APIs to upload and rotate renewed certificates via Secret Manager.

What custom ACME rotation with Secret Manager is

Why it doesn't meet the requirements

Target SSL Proxy Mismatch: External Application Load Balancers (Layer 7 HTTP/HTTPS) require a Target HTTPS Proxy, not a Target SSL Proxy (which is strictly used for Layer 4 TCP proxy load balancing).
High Maintenance & Operational Overhead: Building custom ACME integration and renewal scripts creates unnecessary operational complexity, failure modes, and security overhead compared to using native Certificate Manager.
Self-signed Fallback Issues: Self-signed certificates cause severe browser security warnings and SSL handshake termination errors during the initial cutover phase before ACME issuance completes.

Key characteristics and limitations

Introduces complex secret rotation logic in the CI/CD pipeline.
Relies on non-native tooling rather than fully managed Google Cloud services.
Target SSL proxies do not support HTTP/HTTPS layer-7 routing rules, host matching, or Certificate Maps.

This answer would be correct if

You were building a Layer 4 TCP proxy service requiring custom mutual TLS (mTLS) or handling legacy protocols that cannot utilize Google Cloud managed Certificate Manager automation.

View source documentation

Create Load Balancer-managed certificates referencing HTTP authorizations, deploy a URL map path-matcher rule forwarding `/.well-known/acme-challenge/` to a backend bucket, attach the certificates directly to the target HTTPS proxy, and shift DNS A records to trigger validation.

What HTTP-based validation and direct Target HTTPS Proxy attachment is

Why it doesn't meet the requirements

Fails Wildcard Support: Public Certificate Authorities (such as Let's Encrypt or Google Trust Services) do not permit HTTP-01 or HTTP-based challenge tokens for wildcard domains; wildcard verification strictly requires DNS-01 / DNS-based authorization.
Pre-provisioning Failure & Downtime Risk: HTTP validation requires the domain's public DNS A/AAAA records to route to the load balancer before the certificate can be validated and issued. Switching DNS to an uncertified endpoint results in immediate TLS handshake failures and customer downtime during the provisioning window.
Scalability Limitations: Direct target HTTPS proxy attachment is constrained by strict resource quotas (maximum 15 SSL certificates per target proxy), failing enterprise multi-tenant scale requirements.

Key characteristics and limitations

Lacks support for pre-validation before DNS traffic cutover.
Incapable of issuing wildcard certificates.
Subject to target HTTPS proxy certificate limits.

This answer would be correct if

You were provisioning a single, non-wildcard domain where the DNS had already been pointed to Google Cloud and advanced Certificate Manager map structures were not required.

View source documentation

Create Certificate Manager DNS authorizations, publish the generated CNAME challenge records to the authoritative DNS provider, provision Google-managed certificates referencing these DNS authorizations, map the certificates to domain entries within a Certificate Map, and attach the Certificate Map to the target HTTPS proxy.

What Certificate Manager DNS Authorization and Certificate Maps Are

How it meets the requirements

Pre-provisioning and zero downtime: Creating DNS authorizations allows domain control validation (DCV) to complete via DNS CNAME challenge records before cutting over production traffic. This ensures that Google-managed certificates are issued, verified, and in an ACTIVE state before modifying customer-facing DNS records.
Wildcard and legacy traffic support: DNS authorization is mandatory for validating wildcard domains (e.g., *.example.com) and allows provisioning certificates for domains currently serving live traffic on third-party infrastructure without requiring downtime or temporary HTTP routing.
Scalability via Certificate Maps: Using a Certificate Map with granular Certificate Map Entries allows decoupling certificate associations from the target HTTPS proxy, bypassing legacy quotas (such as the target proxy limit of 15 certificates) and automating continuous certificate renewals without redeploying the load balancer.

Key advantages and capabilities

Automated Renewals: Certificate Manager automatically tracks certificate expiration and renews certificates using the established DNS authorization challenge records without administrator intervention.
High Capacity: Supports up to hundreds of thousands of certificates per load balancer using map entries.
Decoupled Architecture: Enables infrastructure-as-code CI/CD pipelines to independently manage DNS authorizations, certificates, and mapping entries without modifying proxy configurations.

Why this is optimal

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Pre-provisioning Wildcard Certificates with DNS Authorization and Certificate Maps

Explanations

Create a global Certificate Map with fallback wildcards, attach the map to the forwarding rule, and configure Cloud DNS peering to automatically issue Google-managed certificates without external DNS records.

What this architectural configuration proposes

Why it doesn't meet the requirements

Key characteristics and limitations

This answer would be correct if

Generate self-signed fallback certificates, attach them to the Target SSL Proxy, and configure a Cloud Run job in the CI/CD pipeline to query Let's Encrypt ACME APIs to upload and rotate renewed certificates via Secret Manager.

What custom ACME rotation with Secret Manager is

Why it doesn't meet the requirements

Key characteristics and limitations

This answer would be correct if

Create Load Balancer-managed certificates referencing HTTP authorizations, deploy a URL map path-matcher rule forwarding /.well-known/acme-challenge/ to a backend bucket, attach the certificates directly to the target HTTPS proxy, and shift DNS A records to trigger validation.

What HTTP-based validation and direct Target HTTPS Proxy attachment is

Why it doesn't meet the requirements

Key characteristics and limitations

This answer would be correct if

What Certificate Manager DNS Authorization and Certificate Maps Are

How it meets the requirements

Key advantages and capabilities

Why this is optimal

Try 10 interactive questions like this one, free

Related questions

Workload Identity Federation Attribute Conditions

Restrict CMEK Crypto Key Projects

GMP ClusterPodMonitoring Metric Relabeling Drop

Global External Load Balancer Capacity Overflow

Cost of Additional Nines

Dataform for BigQuery ELT

Pre-provisioning Wildcard Certificates with DNS Authorization and Certificate Maps

Explanations

Create a global Certificate Map with fallback wildcards, attach the map to the forwarding rule, and configure Cloud DNS peering to automatically issue Google-managed certificates without external DNS records.

What this architectural configuration proposes

Why it doesn't meet the requirements

Key characteristics and limitations

This answer would be correct if

Generate self-signed fallback certificates, attach them to the Target SSL Proxy, and configure a Cloud Run job in the CI/CD pipeline to query Let's Encrypt ACME APIs to upload and rotate renewed certificates via Secret Manager.

What custom ACME rotation with Secret Manager is

Why it doesn't meet the requirements

Key characteristics and limitations

This answer would be correct if

Create Load Balancer-managed certificates referencing HTTP authorizations, deploy a URL map path-matcher rule forwarding /.well-known/acme-challenge/ to a backend bucket, attach the certificates directly to the target HTTPS proxy, and shift DNS A records to trigger validation.

What HTTP-based validation and direct Target HTTPS Proxy attachment is

Why it doesn't meet the requirements

Key characteristics and limitations

This answer would be correct if

What Certificate Manager DNS Authorization and Certificate Maps Are

How it meets the requirements

Key advantages and capabilities

Why this is optimal

Try 10 interactive questions like this one, free

Related questions

Workload Identity Federation Attribute Conditions

Restrict CMEK Crypto Key Projects

GMP ClusterPodMonitoring Metric Relabeling Drop

Global External Load Balancer Capacity Overflow

Cost of Additional Nines

Dataform for BigQuery ELT

Create Load Balancer-managed certificates referencing HTTP authorizations, deploy a URL map path-matcher rule forwarding `/.well-known/acme-challenge/` to a backend bucket, attach the certificates directly to the target HTTPS proxy, and shift DNS A records to trigger validation.

Create Load Balancer-managed certificates referencing HTTP authorizations, deploy a URL map path-matcher rule forwarding `/.well-known/acme-challenge/` to a backend bucket, attach the certificates directly to the target HTTPS proxy, and shift DNS A records to trigger validation.