Merge pull request #41074 from niranjandarshann/secret/alternativetosecret

Updated the page in correct format

Author: k8s-ci-robot

content/en/docs/concepts/configuration/secret.md

@@ -72,18 +72,18 @@ Rather than using a Secret to protect confidential data, you can pick from alter
 
 Here are some of your options:
 
-- if your cloud-native component needs to authenticate to another application that you
+- If your cloud-native component needs to authenticate to another application that you
   know is running within the same Kubernetes cluster, you can use a
   [ServiceAccount](/docs/reference/access-authn-authz/authentication/#service-account-tokens)
   and its tokens to identify your client.
-- there are third-party tools that you can run, either within or outside your cluster,
+- There are third-party tools that you can run, either within or outside your cluster,
   that provide secrets management. For example, a service that Pods access over HTTPS,
   that reveals a secret if the client correctly authenticates (for example, with a ServiceAccount
   token).
-- for authentication, you can implement a custom signer for X.509 certificates, and use
+- For authentication, you can implement a custom signer for X.509 certificates, and use
   [CertificateSigningRequests](/docs/reference/access-authn-authz/certificate-signing-requests/)
   to let that custom signer issue certificates to Pods that need them.
-- you can use a [device plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
+- You can use a [device plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
   to expose node-local encryption hardware to a specific Pod. For example, you can schedule
   trusted Pods onto nodes that provide a Trusted Platform Module, configured out-of-band.