azd supports a few "pickers" for parameters without default values today e.g.,

@metadata({
    azd: {
        type: 'location'
    }
})
param frontendLocation string

Just like for any parameter named location, you'll prompt with a list of locations. This is also supported for a couple other types like generate.

It would be great to add support to query resources of a specific type e.g.,

@metadata({
    azd: {
        type: 'resource'
        resourceType: 'Microsoft.OperationalInsights/workspaces'
    }
})
param frontendLocation string

This would list all the resources of that type discoverable to the user. Ideally, the display would put the location in parenthesis since they may want to limit those resources to just a location but you would have a hard time doing it above in any meaningful way because you'd either have to author it up front (not flexible), tie it to the location parameter (which you'd have to parse as an expression), or maybe just define a useLocation: bool parameter and use the location after you've already prompted/assigned it. Not sure how useful any of that would be, but listing names like "{name} ({location})" would be easy and useful, since ARM gives you back the locations as well.

E.g. az CLI command:

az resource list --resource-type Microsoft.OperationalInsights/workspaces

Scenarios

The reason why this would be useful is to provide a friendly interface for selecting resources you may want to reuse like AppInsights workspaces (often aggregates apps; this is my impetus for filing this feature request), dashboards (again, often aggregates), or for more expensive resources with multi-project support like Cognitive Services that may also pull from different organizational resources anyway.

It's possible now by passing an environment variable and using that in your .parameters.json file, but it's more work up front and doesn't really fit the UX you already have: you prompt for subscription and location already. Those could also be passed as required parameters but you provide a friendly UX to list them. Getting the resource ID of an existing resources can be a rather daunting task, so it seems that could be made easier as well for those "Getting started" scenarios that some azd users are trying to provide for their downstream users e.g., if we used azd in our Azure SDKs' "Getting started" sections instead of az CLI commands.