Point ZopNight at your own account

Outcome

By the end of this lesson, you will be able to connect your own sandbox or trial cloud account, find what discovery brings back, and schedule one resource of your own.

1. Concept

Everything you have done so far in this course has acted on somebody else’s resources: an estate that already existed, discovered and scheduled. This part of the capstone is yours, in your own sandbox or trial cloud account.

What you need in the account

A CLOUD ACCOUNT     a sandbox or free-trial account on AWS, GCP or Azure,
                    not a production one
ONE RESOURCE        something small you are free to stop: a single VM is
                    enough
READ + WRITE        connect it at the read_write level, from M1.1

The permission level matters. At read_only, ZopNight can discover the resource, but attaching it to a schedule is refused with “write actions are not allowed for read-only cloud accounts”. For a schedule to attach and fire, the account must be read_write.

Why the order is fixed

Discovery reads the cloud account. A schedule acts on what discovery found. So the sequence is:

connect the account → discovery runs → the resource appears → attach a schedule

If your resource is not in ZopNight yet, the usual answer is that discovery has not run since you created it, not that something is broken. Discovery runs every 6 hours, and the manual refresh from M1.2.L5 (through the API) runs it now.

What is schedulable, and what is not

Not everything in an account can be stopped on a clock. From the supported list, these are the shapes you are most likely to have in a sandbox:

SCHEDULABLE        EC2 instances, Compute Engine VMs, Azure Virtual
                   Machines, EKS/GKE/AKS node groups, RDS and Cloud SQL
                   instances, ECS services, Cloud Run, Container Apps

NOT SCHEDULABLE    the load balancer, the static IP, the registry,
                   the storage bucket. They cost money but there is
                   nothing to stop.

An account whose only footprint is serverless has a smaller schedule story and a bigger rightsizing one. That is not a failure of the exercise, it is the answer.

2. Demo

START       sandbox account connected at read_write, one small VM running
STEP 1      discovery runs (or a manual refresh)
STEP 2      ZopNight lists the VM under that account and region
STEP 3      attach it to a nightly schedule, 19:00 stop, 08:00 start
RESULT      the VM shows stopped after 19:00 and running again after 08:00,
            and the history names the schedule as the trigger

That last line is the whole course in one sentence: a resource you own now costs money only while somebody could be using it.

3. Hands-on (6 min)

1. Connect your sandbox or trial account in ZopNight at read_write,
   if you have not already (M1.1). At read_only, step 4 is refused.
2. Find your resource. Filter by the account and the region.
3. If it is not there, trigger a discovery refresh and wait.
4. Attach it to a schedule: stop at 19:00, start at 08:00, in your
   own timezone.
5. Note which resources in the account are NOT schedulable, and why.
6. Wait for the next firing, or set the schedule a few minutes out
   so you can watch it happen. Check the resource's state history.

Do it through MCP. The same task you just did in the console, asked in one sentence.

BEFORE  Your sandbox account connected, and the resource discovered.
ASK     "Find the VM in my sandbox account and put it on a 19:00 to 08:00 schedule."
CHECK   the schedule lists the VM, and nothing unstoppable such as a load balancer. A schedule that claims to cover something unstoppable is the mistake this lesson is guarding against.

Tools behind it: get_discovery_summary (read, Explore), list_resources (read, Explore), create_schedule (write, tier 2, reversible), attach_resource_to_schedule (write, tier 2, reversible). Connection details are in the MCP integration docs.

4. Knowledge check

Q1

You created a VM in your sandbox account an hour ago, but it does not appear in ZopNight. The first thing to check:

A. Whether write access is enabled for the assistant
B. Whether discovery has run since you created the VM
C. Whether the VM has a public IP address
D. Whether the account was connected at read_only

Q2

Which of these, in a typical sandbox account, cannot be put on a schedule?

A. The EC2 instance
B. The load balancer
C. The RDS instance
D. The node group under the cluster

Q3

Your account is connected at read_only. You try to attach the VM to a schedule so it stops at 19:00. What happens?

A. The VM stops at 19:00, because schedules ignore the permission level
B. The attach succeeds, but the executor skips the VM at every firing
C. The attach is rejected: write actions are refused on read_only accounts
D. The account is upgraded to read_write automatically at the first firing

5. Apply

The honest test of this lesson is the history entry after 19:00. If the resource did not stop, one of four things is true: the schedule is not attached to it (a read_only account refuses the attach), the account was switched to read_only after you attached it, the resource type is not schedulable, or the schedule has not fired yet.

KEEP
  the cloud account and the resource you scheduled
  the schedule name
  the first firing, from the history view

Related lessons

• L2: Drive it through MCP
• T1.M1.2.L5: When discovery is stale
• T1.M1.3.L5: Attaching resources and groups

Glossary terms touched

Schedule · Resource group