A child resource is a control-plane object whose identity and lifecycle are anchored under a parent resource. In ARM and Bicep reviews, I look at child resources to understand the real shape of the deployment, because important configuration often lives below the top-level object: subnets under virtual networks, diagnostic settings, SQL firewall rules, storage service settings, secrets, extensions, and application components. The architecture decision is not just nesting syntax; it is ownership, scope, API versioning, delete behavior, and dependency clarity. Good templates make parent-child relationships obvious, avoid brittle string-built names, and show whether a child is deployed inline, separately, or as an existing reference needed by another module.
SecuritySecurity for Child resource starts with understanding which parent resources, child configuration, deployment identities, provider operations, template parameters, and resource IDs are exposed or changed. Review who can view, change, or use it, and confirm production access follows least privilege. Check whether private networking, RBAC, managed identity, Key Vault, diagnostic settings, policy assignments, audit logs, and data classification apply. Operators should avoid exposing secrets, tokens, prompts, certificates, customer data, or internal identifiers in troubleshooting output. A secure design documents emergency access, rotation ownership, and evidence retention so incident responders can prove the current configuration without inventing access during an outage.
CostCost for Child resource comes from the resources, transactions, storage, data movement, retention, capacity, tokens, monitoring, or operational labor it influences. Some costs are direct meters, while others appear as extra retries, duplicate processing, longer investigations, unneeded resources, or higher support effort. Review budgets, allocation tags, usage metrics, SKU limits, and retention settings before scaling or enabling new behavior. The safest approach is to define the owner, expected usage pattern, and alert thresholds up front so finance conversations use evidence instead of opinions after the bill arrives. Operators should record owner, scope, evidence, and rollback expectations before production changes. Reviewers should confirm the approved design, current telemetry, and support path before accepting risk.
ReliabilityReliability for Child resource depends on whether the design behaves predictably during scale events, regional incidents, expired credentials, throttling, schema changes, or downstream failures. Identify the dependency chain, expected failure mode, and recovery target before production use. Monitor signals such as health state, retries, backlog, lag, latency, authentication failures, quota pressure, or stale data. Test restore, rotation, failover, replay, rollback, or reprocessing paths where they apply. Operators need a runbook that separates platform configuration problems from application defects and states which evidence is required before escalation. Operators should record owner, scope, evidence, and rollback expectations before production changes. Reviewers should confirm the approved design, current telemetry, and support path before accepting risk.
PerformancePerformance for Child resource is about how quickly and consistently the related workload can complete useful work. Measure the right signals: latency, throughput, backlog, request volume, token count, CPU, memory, bytes processed, retries, cache behavior, or throttled operations depending on the service. Avoid tuning one setting in isolation when identities, network paths, partitions, downstream services, client behavior, or data layout may be the real bottleneck. Performance reviews should compare expected workload shape with live metrics and include a safe test plan before increasing capacity or changing production configuration. Operators should record owner, scope, evidence, and rollback expectations before production changes.
OperationsOperationally, Child resource needs ownership, naming, tagging, change records, and repeatable verification. Teams should know where it appears in the portal, which commands or queries prove state, which dashboards show health, and which settings are safe to change during business hours. Keep examples, approvals, and rollback notes with the service runbook rather than in personal notes. For production changes, capture current configuration before and after the work, including resource IDs, region, owner, timestamp, and related deployment. Good operations turn the term into a checklist first responders can follow under pressure. Operators should record owner, scope, evidence, and rollback expectations before production changes.