Cram sheet — Provision and manage containers in the Azure portal
AZ-104 › Unit 3 › Provision and manage containers in the Azure portal
Cram sheet — Provision and manage containers in the Azure portal
Provision and manage containers in the Azure portal
- AZ104-U3.T3
- 4
- 19
- 4
Three container services with three different jobs: a registry that stores images, an instance service that runs one task, and a platform that runs an application. Most questions here are asking which of the three the requirement describes.
Container Registry: the tiers differ by capacity, then by feature
- Three plans: Basic, Standard, Premium.
- All three provide the same programmatic capabilities and data plane APIs, and all have zone redundancy enabled by default in supported regions. Basic is not a cut-down API.
- What separates them first is included storage and image throughput. What separates Premium specifically is the feature set: geo-replication — one registry managed across multiple regions — plus private link with private endpoints, and higher concurrency.
- So a stem asking for a registry in several regions under one name, or a registry reachable only privately, is asking for Premium and nothing else will do.
Container Instances: groups and restart policy
- A container group is containers scheduled on the same host machine, sharing a lifecycle, resources, local network, and storage volumes. The documentation's own analogy is a Kubernetes pod.
- ⚠ Multi-container groups support only Linux containers. For Windows, Azure Container Instances supports deployment of a single container instance only. This is the single most reliable elimination in the topic.
- A group's resources are the sum of its instances' requests: two containers asking for one CPU each means the group is allocated two.
- Restart policy has three values, and
Alwaysis the default applied when none is specified:
| Policy | Behaviour |
|---|---|
| Always (default) | Containers are always restarted |
| OnFailure | Restarted only on a nonzero exit; containers run at least once |
| Never | Not restarted after a successful (exit code 0) finish |
Container Apps: the environment is the boundary
- A Container Apps environment is a secure boundary around one or more container apps and jobs, and the runtime handles OS upgrades, scaling, failover and resource balancing.
- ⚠ Apps in the same environment share the same virtual network and write logs to the same logging destination. That is the reason to put apps together — and the reason to keep them apart when they must be isolated.
Traps
Check yourself
Where these figures come from
Every figure above was read from the raw documentation below on the day this sheet was written. The sha1 is git hash-object over the bytes as fetched, so a doc that changes underneath this sheet can be detected rather than assumed.
| Document | sha1 |
|---|---|
| Azure Container Registry service tiers | 7541b839696f |
| Introduction to container groups | 706cf3b4c541 |
| Restart policy for run-once tasks | 7a520bfd1207 |
| Azure Container Apps environments | a2e3bdd87bd5 |