1. Yes, these will be stored in the container logs on the physical node that was responsible for running the job. Additionally, the pod details/state will be retained inside of Kubernetes based on the jobs retention:

https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically

2. Yes, jobs use the standard spec.Pod specification. Meaning you can have multiple containers running inside of a single pod (ran by the job)

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#jobspec-v1-batch https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#podtemplatespec-v1-core

3. What do we mean by this? The Kube API is the best way, you can check for the job being triggered and check the status of this job. This typically provides the status of a job:

  status:
    completionTime: "2019-10-21T02:13:16Z"
    conditions:
    - lastProbeTime: "2019-10-21T02:13:16Z"
      lastTransitionTime: "2019-10-21T02:13:16Z"
      status: "True"
      type: Complete
    startTime: "2019-10-21T01:00:08Z"
    succeeded: 1

4. Yes, in the same way pods are given unique identifiers, when a cronjob is triggered a job with a unique identifier is created:

user:~$ kubectl get jobs -n elasticsearch
NAME                                                   COMPLETIONS   DURATION   AGE
elasticsearch-elastic-stack-kibana-backup-1571443200   1/1           5s         2d4h
elasticsearch-elastic-stack-kibana-backup-1571529600   1/1           5s         28h
elasticsearch-elastic-stack-kibana-backup-1571616000   1/1           5s         4h58m