Select the run explicitly

bin/vulnvm ls
bin/vulnvm status -n telco-easy-1
bin/vulnvm outputs -n telco-easy-1

List shows the local run records. Status combines the stored run with live AWS resource information when valid credentials are available. Outputs shows entry points and deployment details, but can fall back to cached Terraform outputs. A printed address is not proof that a service is currently healthy.

Without -n, commands resolve the sole active run. If several runs are active, the CLI stops and requires -n RUN. Use explicit names in exercise notes and automation so the intended environment remains clear.

Separate infrastructure logs from exercise evidence

bin/vulnvm logs -n telco-easy-1
bin/vulnvm logs -n telco-easy-1 -f
bin/vulnvm logs -n telco-easy-1 --tail 200

These commands read the run's Terraform log at .vulnvm/runs/telco-easy-1/terraform.log. Use them for planning, resource creation or deletion failures. They do not stream every portal request or the Kubernetes behavior runner.

Application and behavior logs describe exercise activity. Runtime events include request and trace identifiers that connect the portal, provisioning and inventory chain. Behavior evidence records expected and observed status, outcome, latency and the plan digest without headers or response bodies. Keep these sources distinct when investigating an incident.

Inspect Kubernetes in the intended context

bin/vulnvm kubeconfig -n telco-easy-1
bin/vulnvm workloads -n telco-easy-1 -N vulnvm-telecom

Kubeconfig writes an AWS EKS context for the selected run. Workloads uses that named context to show deployments, pods, services and TargetGroupBindings. Confirm that the telecom runtime was installed before interpreting an empty namespace as a failed application.

For this slice, expect the portal, provisioning, inventory and one behavior runner. The runner has no Service and its network policy permits DNS and portal access. A running Pod is not enough: inspect readiness and recent behavior evidence as described in runtime readiness.

Resolve failures at the layer that owns them

Identity or access failure
Refresh the intended SSO session and check its account. Verify the recorded stable EKS role and current operator IPv4 address before retrying. Do not replace role bindings to work around a refusal.
Terraform operation fails
Read the run log, preserve state and inspect live status. An interrupted command can leave resources behind. Confirm the failed operation's state before choosing a retry or teardown.
Image does not start
Check the immutable image reference, GHCR public visibility and Pod events. An image pull problem is different from application readiness.
Behavior becomes unready
Check which profile stopped producing fresh expected responses. Compare event plan digests with the digest in run status, then inspect portal dependency health.
Outputs exist but the page is unreachable
Check live ALB and EC2 status and whether the workstation still uses the allowed address. Cached outputs can survive a failed operation.

Plan changes and watch resource lifetime

Use a new named range for a changed scenario, tier or deployment configuration. The CLI does not update an already deployed run, and retries preserve the original run binding. Names remain reserved after destruction, so a new exercise also needs a new name. Start with a complete easy telecom cycle before larger tiers.

Higher tiers increase capacity, telemetry retention, data and synthetic activity. Track AWS budgets and account usage through your cloud tools. The default TTL is eight hours and can be configured before creation, but expiry only creates reminders and tags. It does not stop resources or billing.

Verify cleanup before closing the exercise

bin/vulnvm destroy -n telco-easy-1 --plan-only
bin/vulnvm destroy -n telco-easy-1
bin/vulnvm ls

Destroy first removes installed application workloads, then the load balancer controller, then Terraform resources. The saved destroy plan is bound to its unchanged Terraform state snapshot. The CLI marks the run destroyed only after managed inventory and root outputs are empty.

Inspect the AWS account afterwards for residual resources and unexpected ongoing usage. The legacy procedure does not include an independent automated AWS residual inventory probe. If cleanup fails, retain the run record and logs, identify the remaining resources and continue through the recorded run. Do not delete local state to make the range disappear from the list.