Implement generative AI and agentic solutions 2.1 Build generative applications by using Foundry

A hosted agent's azure.yaml sets the environment variable GITHUB_TOKEN to…

Study guide skill: Integrate generative workflows into applications by using Foundry SDKs and connectors

Question B6-018

A hosted agent's azure.yaml sets the environment variable GITHUB_TOKEN to ${{connections.agent-secrets.credentials.github_token}}. After the agent version is deployed, the variable is empty when the code reads it inside the running container. What's the most likely cause?

Select one answer.

  • A The token must also be hard-coded in the container image as a fallback
  • B The agent-secrets connection, or its github_token field, didn't exist when the sandbox started, so the placeholder didn't resolve ✓ Correct answer
  • C The placeholder must name a Key Vault secret that was created earlier outside Foundry
  • D Placeholders resolve only when someone calls GET on the agent version

Answer: B

Foundry resolves the placeholder at sandbox start, and if the connection or the referenced field is missing at that point the variable is empty, so create the connection before deploying the version. A GET on the agent version returns the literal placeholder text, and secrets are verified by reading the variable inside the running container. Foundry chooses the backing Key Vault secret name, so you can't reference a preexisting secret by name, and the feature exists so you don't hard-code secrets.

Deep dive

How it works

Instead of hard-coding secrets into azure.yaml or your image, a hosted agent can reference a Foundry project connection in an environment variable with a placeholder like ${{connections.agent-secrets.credentials.github_token}}.

The timing is what matters here:

  • At sandbox start, Foundry resolves the placeholder and injects the resolved value as a plain environment variable.
  • If the connection or the referenced field is missing at sandbox start, the placeholder doesn't resolve and the variable is empty. That's the symptom in the question.
  • So create the connection before you deploy the version.

Two more details. A GET on the agent version returns the literal ${{...}} text, because the resolved secret is never echoed back through the management API, so to check the value you read the variable inside the running container. And when you create the connection, Foundry stores the value in Key Vault under a name it chooses. You can't reference a preexisting Key Vault secret by name.

The other options, and when you'd use them

  • Hard-code a fallback in the image: The feature exists so you don't hard-code secrets in azure.yaml or the image.
  • Name an existing Key Vault secret: Foundry chooses the backing secret name, and you can't reference a preexisting secret by name.
  • Resolves only on GET: The opposite. GET returns the literal placeholder text. Resolution happens at sandbox start.

Exam tip

Empty secret env var in a hosted agent = connection or field missing at sandbox start. Create the connection first, then deploy.

References

Last reviewed:

Ready to test yourself? The quiz asks this and every other AI-103 question, with instant feedback. Practice this in a quiz →

All Generative AI & agents questions · AI-103 study guide

Thanks for your feedback!