`apimanagement.Service`: pulumi-azure says `client_certificate_enabled` must be `False` but Azure API says it must be `True`

[codethief]

Describe what happened

I'm deploying an pulumi_azure.apimanagement.Service with sku_name="Developer_1". After setting client_certificate_enabled=True, running pulumi up will have the pulumi-azure provider complain that

Diagnostics:
  azure:apimanagement:Service (my-apim):
    error:   sdk-v2/provider2.go:566: sdk.helper_schema: `client_certificate_enabled` is only supported when sku type is `Consumption`: provider=azurerm@6.22.1
    error: 1 error occurred:
    	* updating urn:pulumi:dev::my-project::<parent component>$azure:apimanagement/service:Service::my-apim: 1 error occurred:
    	* `client_certificate_enabled` is only supported when sku type is `Consumption`

which is also what the API docs say.

However, when setting client_certificate_enabled=False, pulumi up yields:

Service Name: "my-apim"): performing Update: unexpected status 400 (400 Bad Request) with error: EnableClientCertificateCannotBeChangedForSku: Setting EnableClientCertificate flag to false is not supported for Developer SKU.

As a result, I can only set client_certificate_enabled=None and trust that the default is (and stays) what I want.

Sample program

Writing a fully reproducible program is difficult because of all the other resources you need to deploy an API Management service but the gist is:

import pulumi_azure

pulumi_azure.apimanagement.Service(
    resource_name="my-apim",
    sku_name="Developer_1",
    client_certificate_enabled=True,
    # …
)

Log output

See above

Affected Resource(s)

pulumi_azure.apimanagement.Service

Output of pulumi about

$ pulumi about
CLI
Version      3.178.0
Go Version   go1.24.4
Go Compiler  gc

Plugins
KIND      NAME          VERSION
resource  acme          0.10.0
resource  azure         6.22.1
resource  azure-native  3.4.0
language  python        3.178.0
resource  time          0.1.1
resource  tls           5.2.0

Host
OS       nixos
Version  25.11 (Xantusia)
Arch     x86_64


This project is written in python: executable='/path/to/my-project/.venv/bin/python' version='3.12.11'

Current Stack: organization/my-project/dev

[…]

Backend
Name           my-hostname
URL            azblob://…
User            my-user
Organizations
Token type     personal

Dependencies:
NAME                   VERSION
Jinja2                 3.1.6
nodejs-wheel-binaries  22.16.0
pulumi_azure           6.22.1
pulumi_azure_native    3.4.0
pulumi_tls             5.2.0
pulumiverse_acme       0.10.0
pulumiverse_time       0.1.1
pydantic               2.11.4
pyright                1.1.401
pytest-mock            3.14.0

Pulumi locates its logs in /tmp by default

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[codethief]

Having done a bit of research, I believe this is actually an upstream issue in terraform-provider-azurerm or at least that's where the error message originates:

https://github.com/hashicorp/terraform-provider-azurerm/blob/a6f0f4e514d3f1ea536b89dbce0e98e436e9a283/internal/services/apimanagement/api_management_resource.go#L895

https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/api_management#client_certificate_enabled-3

client_certificate_enabled - (Optional) Enforce a client certificate to be presented on each request to the gateway? This is only supported when SKU type is Consumption.

[codethief]

Notably, it seems pulumi-azure-native's documented interface is the same as that of pulumi-azure / terraform-provider-azurerm:

enable_client_certificate: Property only meant to be used for Consumption SKU Service. This enforces a client certificate to be presented on each request to the gateway. This also enables the ability to authenticate the certificate in the policy on the gateway.

I haven't tested, though, whether pulumi-azure-native throws an error, too.

[corymhall]

@codethief thanks for reporting the issue and doing the additional research! It does look like an upstream issue which means the fix would have to be there. Once the upstream provider has the fix we will inherit it.